Re: Unsolicited Data.

[julian_satran@il.ibm.com]

It may vary from command to command. A simple cdesign may decide to send
immediate data only when it will contain all it has to send and send in
separate PDUs if it has more (solicited or unsolicited).
I saw no real reason to enforce a behavior or other.

Julo

"Sanjeev Bhagat \(TRIPACE/Zoetermeer\)" <sbhagat@tripace.com> on 07-06-2001
02:05:39

Please respond to "Sanjeev Bhagat \(TRIPACE/Zoetermeer\)"
      <sbhagat@tripace.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: Unsolicited Data.




Hello,

All that is said below is ok but I cannot understand one thing here
----- why would initiator choose not to send unsolicited immediate data
when
it has negotiated for IntialR2T= Yes??

Sanjeev


----- Original Message -----
From: "Ayman Ghanem" <aghanem@cisco.com>
To: <ips@ece.cmu.edu>
Sent: Wednesday, June 06, 2001 6:48 PM
Subject: RE: Unsolicited Data.


> That section was modified. Julian posted the revised text here:
>
> http://ips.pdl.cs.cmu.edu/mail/msg04647.html
>
> -Ayman
>
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
> > Sent: Wednesday, June 06, 2001 9:36 AM
> > To: 'ips@ece.cmu.edu'
> > 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
> > >
> > >
> >
>