RE: Unsolicited Data.

["BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>]

Hi Julian

Sorry about harking on with this one but I still don't feel that it has been
resolved.

By the new text are you referring to
http://ips.pdl.cs.cmu.edu/mail/msg04647.html?

If so it does not take into account the issue that I am trying to resolve:
If an initiator and target have negotiated to use unsolicited data
PDUs(InitialR2t=no), how does an target know that an initiator is going to
sent unsolicited SCSI Data PDUs when it is optional to send unsolicited data
PDUs?

Mallikarjun has suggested a solution which will work providing that
immediate data and unsolicited Data PDUs can not be used together (which is
what Rev 06 states). Am I correct it believe this is still the case - I seem
to remember a thread suggesting otherwise.

The other option, which is less flexible is that if both sides have
negotiated to use unsolicited Data PDUs (InitialR2t=no), then it MUST always
send unsolicited data which needs to be reflected in the specification.

Cheers

Matthew



-----Original Message-----
From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
Sent: Sunday, June 10, 2001 12:32 PM
To: ips@ece.cmu.edu
Subject: RE: Unsolicited Data.




I've published the new text to this list a while ago. Please look-up the
archives. Julo

"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com> on
06-06-2001 17:35:38

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

To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  RE: Unsolicited Data.





The current spec states that the F bit is "set to 1 when the immediate data
that accompany the command are all the data associated with this command.
It
is an error if the Length and Expected Length do not match and this bit is
set to 1".

I interpret this as there is no more data to follow and not that the
initiator has opted not to use the unsolicited data feature.  Therefore the
spec needs to be modified to indicate that if unsolicited data has been
negotiated (i.e. InitialR2T=no), then the initiator MUST send unsolicited
data of length = min( FirstBurstSize, ExpectedTransferLength ) minus any
immediate data sent).

Matthew Burbridge
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: matthewb@bri.hp.com


-----Original Message-----
From: Ayman Ghanem [mailto:aghanem@cisco.com]
Sent: Tuesday, June 05, 2001 6:31 PM
To: ips@ece.cmu.edu
Subject: RE: Unsolicited Data.


If the initiator decides not to send immediate or unsolicited data when it
has negotiated to do so, then the initiator must set the F-bit in the
command PDU. This prompts the target to send R2T.

I still agree that the spec should indicate that the initiator MUST use the
resources it has negotiated. If it has negotiated the option to send
immediate data or unsolicited data then it should do that to the limits
allowed. If it has negotiated a PDU length, it must not send data PDUs less
than the negotiated limit except for last one. While most implementation
may
do that for performance reasons, I would prefer defining this in the spec.

-Ayman

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
> Sent: Tuesday, June 05, 2001 11:58 AM
> To: 'ips@ece.cmu.edu'
> Subject: Unsolicited Data.
>
>
> I'm not sure if this has been discussed before but it is causing some
> confusion.  The statement below implies that if immediate data has been
> negotiated then the initiator MAY use it.
>
> "If ImmediateData is set to no and InitialR2T is set to no then the
> initiator MUST NOT send unsolicited immediate data but MAY send one
> unsolicited burst of Data-OUT PDUs."
>
> Therefore the target must wait for the initial burst of unsolicited data
> before issuing the first R2T (if there is subsequent data).  If the
> initiator decides not to send it then the target must timeout and
> issue the
> R2T for the initial data.  Can the spec be changed to state that if
> unsolicited data has been negotiated, then the initiator MUST use it.
>
> Thanks
>
> Matthew Burbridge
> NIS-Bristol
> Hewlett Packard
> Telnet: 312 7010
> E-mail: matthewb@bri.hp.com
>
>