Re: Unsolicited Data Questions

["Mallikarjun C." <cbm@rose.hp.com>]

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"
>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?
>
>2) Appendix D 29: KeyValueText: default value is outside of parameter range.
>
>Cheers
>
>Matthew Burbridge
>Hewlett Packard, Bristol
>Telnet: 312 7010
>E-mail: matthewb@bri.hp.com
>
>