Re: Unsolicited Data Questions

[julian_satran@il.ibm.com]

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"
>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
>
>