RE: iSCSI: immediate data

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

Hi Julian,

Rev 06 specifies that immediate and unsolicited data can not be mixed. E-22
page 128 (is there a typo - see below).  But if using immediate data,
providing that the  F bit is zero, can you confirm that the target is able
to issue an R2T for the remaining data. i.e. immediate and solicited data is
supported.

The typo (pg 128):
   If ImmediateData is set to yes and InitialR2T is set to NO (typo: was
yes) then the 
   initiator MAY send unsolicited immediate data or one unsolicited 
   burst of Data-OUT PDUs but MUST NOT send both immediate and a 
   unsolicited burst of Data-OUT PDUs for any one command. 

Cheers

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


> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: 10 May 2001 15:25
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: immediate data
> 
> 
> 
> 
> Matt,
> 
> F is the end of the sequence. If you don't have immediate 
> data but have
> some unsolicited data PDU
> the keep F at 0 until the last unsolicited PDU (presence or absence of
> immediate is indicated by length).
> 
> If you have immediate but no other unsolicited or no 
> immediate and no other
> unsolicited F will be 1.
> 
> Julo
> 
> "Matt Wakeley" <matt_wakeley@agilent.com> on 09-05-2001 19:29:05
> 
> Please respond to Matt Wakeley <matt_wakeley@agilent.com>
> 
> To:   ips@ece.cmu.edu
> cc:
> Subject:  Re: iSCSI: immediate data
> 
> 
> 
> 
> The way I interpret the question is, what if you negotiated 
> immediate data,
> but have no intention on sending immediate data for this command?  Is
> setting
> the F bit, without sending any immediate data valid? (once again, more
> options....)
> 
> -Matt
> 
> julian_satran@il.ibm.com wrote:
> >
> > That is correct. The final bit indicates the end of 
> unsolicited  data.
> > If all you have is immediate then the final bit is 1in the command.
> > If you have immediate and other unsolicited (if enabled!) 
> then set F to
> 0.
> >
> > 2.3.1 has been fixed accordingly.
> >
> > Regards,
> > Julo
> >
> > sandeepj@research.bell-labs.com (Sandeep Joshi) on 
> 09-05-2001 01:56:25
> >
> > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)
> >
> > To:   matt_wakeley@agilent.com
> > cc:   ips@ece.cmu.edu
> > Subject:  Re: iSCSI: immediate data
> >
> > Umm.....Julian replied to this one and said the final bit on ScsiCmd
> > would indicate it.   Apparently, a single command can now send
> > the unsolicited data both with the command and in separate PDUs.
> >
> > I cant seem to find the email but I believe Sec 2.3.1 was changed
> > accordingly.  Julian..?
> >
> > -Sandeep
> >
> > > The intention is that if an initiator requests to send 
> immediate data
> > (and is
> > > granted the request), then it will always send immediate data.
> > >
> > > It sounds like you are asking for wishy washy mode... 
> sometimes send
> > immediate
> > > data, sometimes not.
> > >
> > > -Matt
> > >
> > > Sandeep Joshi wrote:
> > > >
> > > > Julian,
> > > >
> > > > I had a follow-up question on an old thread.
> > > >   http://ips.pdl.cs.cmu.edu/mail/msg03373.html
> > > >
> > > > The initiator is allowed to send firstburst in immediate
> > > > or in separate PDUs...but can it do neither ?  I dont
> > > > see any statement to the effect that it MUST send a
> > > > firstburst.
> > > >
> > > > Here's a possible problem :
> > > > 1) FirstBurst is 4K
> > > > 2) Expected data length of command is 16K
> > > > 3) Initiator sends the Scsi command without immediate
> > > >    data.   (final flag on Scsi command is not set)
> > > >    And it decides to send no further data PDUs.
> > > >
> > > > The target does not know if R2Ts can be sent since it does
> > > > not know if any unsolicited PDUs are expected.
> > > >
> > > > Perhaps the semantics on the final flag on SCSI command
> > > > need to be changed to indicate that no unsolicited data
> > > > will be sent with this command.  Currently, the flag implies
> > > > (Sec 2.3.1) that all the required data has been sent with
> > > > the command.
> > > >
> > > > And here's a typo to fix.  Appendix E (Key=immediateData)
> > > > The following should say "initialR2T is no".
> > > > The table has got it right.
> > > >
> > > > > If ImmediateData is set to yes and InitialR2T is set
> > > > > to yes then the initiator MAY send unsolicited immediate
> > > > > data or one unsolicited burst of Data-OUT PDUs but
> > > > > MUST NOT send both immediate and a unsolicited burst of
> > > > > Data-OUT PDUs for any one command.
> > > >
> > > > -Sandeep
> 
> 
>