RE: Unsolicited Data Questions

[julian_satran@il.ibm.com]

Mathew,

The appendix is correct.  It does not make too much sense to have the first
burst both as immediate and separate PDU. It complicates implementation.
Immediate are meant for short transactions but recall that immediate data
can be large. If you decide to go for separate PDUs then you can as well
drop the immediate - the gain is marginal and checking becomes cumbersome.

For the editorial answers in text.

Thanks,
Julo



Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"
      <matthew_burbridge@hp.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: Unsolicited Data Questions




Hi Julian

I echo Mallikarjun's input on this.

If you still have time, I  would appriciate comments on my original email

Cheers

Matthew


> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: 31 March 2001 07:03
> To: ips@ece.cmu.edu
> Subject: Re: Unsolicited Data Questions
>
>
>
>
> Mallikarjun,
>
> I'll see what I can do. BTW - the second line has also to
> specify - not in
> the same command.
>
> Regards,
> Julo
>
> "Mallikarjun C." <cbm@rose.hp.com> on 30/03/2001 19:38:18
>
> Please respond to cbm@rose.hp.com
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  Re: Unsolicited Data Questions
>
>
>
>
> Julian,
>
> On the subject of unsolicited and immediate data: Perhaps adding
> a table like this might help understand the intent of the draft
> better. (InitialR2T = UseR2T, per earlier discussion)
>
> +-------------+---------------+----------------------------------------+
> | InitialR2T  | ImmediateData |   Result (upto FirstBurstSize)         |
> +-------------+---------------+------------------------------- ---------+
> |  no         |    no         | Unsolicited data in separate PDUs only |
> +-------------+---------------+----------------------------------------+
> |  no         |    yes        | Immediate & separate unsolicited data  |
> +-------------+---------------+----------------------------------------+
> |  yes        |    no         | Unsolicited data disallowed>          |
> +-------------+---------------+----------------------------------------+
> |  yes        |    yes        | Immediate unsolicited data only        |
> +-------------+---------------+----------------------------------------+
>
> --
> Mallikarjun
>
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
> >Hi Julian
> >
> >Sorry if I'm covering old ground...
> >
> >Is it possible to use unsolicited data for the first burst and then
> request
> >any remaining data using R2T?  For example, if the target
> has a previously
> >allocated buffer available (length defined by FirstBurstSize) for
> >unsolicited data, then once the initiator has sent
> unsolicited data up to
> >and including this amount then the remaining data (if any) can be
> requested
> >using R2T once the target has the buffer space available.
> >
> >Section 1.2.5 pertains to this..  "An initiator may send
> unsolicited data
> >either as immediate (up to the negotiated  maximum PDU size -
> DataPDULength
> >- disconnect-reconnect mode page) or in a separate PDU
> sequence (up to the
> >negotiated limit - FirstBurstSize - disconnect-reconnect
> mode page). All
> >subsequent data  has to be solicited"
> >
> >However, Appendix D - 22 ImmediateData" appears to
> contradict this:   "If
> >ImmediateData is set to no and UseR2T is set to yes then the
> initiator
> MUST
> >NOT send unsolicited data and the target MUST reject them with the
> >corresponding response code."
> >
> >Also I have some comments from my colleagues:
> >
> >Page 15: Last paragraph is unclear from 2nd sentence.  The
> hyphens look
> like
> >minus signs. All a bit confusing.
> >Page 16: There are several references to initial burst.
> Should these not
> be
> >changed to first burst to be consistent with the terminology used
> >subsequently in the spec especially since this it's the
> "FirstBurstSize"
+++ fixed text +++
> >which defines how much data can be accepted.
> >page 111: The spec says that you need to set immediateData
> to yes so that
> >you can receive a first burst of immediate data, but then "only
> >immediate data are accepted in the first burst".  If you
> have immediate
> data
> >set to no and R2T set to yes you can't accept any
> unsolicited data: Are
> you
> >stating that immediate data and "normal" unsolicited data can not be
> mixed.
> >
> >1) Section 2.13.1: Is the response to a NOP-In issues by the target,
> always
> >a NOP-out?
> >
+++ yes+++
> >2) Appendix D 29: KeyValueText: default value is outside of parameter
> range.
+++ fixed ++
> >
> >Cheers
> >
> >Matthew Burbridge
> >Hewlett Packard, Bristol
> >Telnet: 312 7010
> >E-mail: matthewb@bri.hp.com
> >
> >
>
>
>
>
>