Subject: RE: iscsi: unsolicited data question

From: Dennis Young <[email-masked]>
Date: Wed, 12 Jun 2002 10:49:53 -0700

Are you saying that, for a session that has InitialR2T=No in effect, the
initiator
must send all its data as unsolicited first, up to the amount negotiated in 
FirstBurstSize, before it waits for a R2T from the target? 
 
Can you shed some light on why we need unsolicited Data-out PDU when there 
is ImmediateData, seems like they both serve the same purpose, having both
of 
them only make the spec more complex.
 
Thanks,
-Dennis
 
 -----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 10:19 AM
To: Dennis Young
Cc: [email-masked]; [email-masked]
Subject: RE: iscsi: unsolicited data question

This is the reason why the initiator is required to send ALL unsolicited
data (target can count on it and start sending R2Ts as soon as it sees the
first header> 
Neither bandwidth nor latency are wasted. 

Julo 

	Dennis Young <[email-masked]> 

06/12/2002 08:05 PM 
Please respond to Dennis Young 

        To:        Julian Satran/Haifa/IBM@IBMIL 
        cc:        [email-masked], [email-masked] 
        Subject:        RE: iscsi: unsolicited data question 

Julian, 
  
This leads me to a more interesting question. 
A session with InitialR2T=No in effect, i.e. unsolicited Data-out 
allowed, could cause unintended waste of bandwidth, depending on 
how fast the target sends our R2T in response to the SCSI Write. 
  
If the target sees the unsolicited Data-out PDU before building the 
R2T, then everything is fine. 
If the target doesn't see the unsolicited Data-out PDU before building 
the R2T, the R2T would request the same portion of data in the 
unsolicited Data-out, thus bandwidth is wasted. 
  
The question is, how can a target be smart about this? 
Should the target wait a moment for the possible unsolicited Data-out 
after receiving each SCSI Write, this sounds kludgy. 
  
Also, why do we need the unsolicited Data-out PDU feature when 
there is ImmediateData? 
  
Regards, 
Dennis 
  
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 6:05 AM
To: Dennis Young
Cc: [email-masked]; [email-masked]
Subject: Re: iscsi: unsolicited data question

yes - julo 

	Dennis Young <[email-masked]> 
Sent by: [email-masked] 

06/12/2002 06:20 AM 
Please respond to Dennis Young 

       To:        [email-masked] 
       cc:         
       Subject:        iscsi: unsolicited data question 

I have a question which has been asked before, but I couldn't find a direct 
answer in the archive.  The table on page 200 of draft 12 doesn't directly
answer this question either.

The first paragraph on page 36 of draft 12 says "Targets operate in either 
solicitied (R2T) data mode or unsolicited (non R2T) data mode."
tells me that a target, at all times during a data sequence transfer, can be

one or the other, but not both (non R2T for the initial data out, R2T for
the
remaining data).  Is this correct?

Thanks,
Dennis

---snip from an old email dated 3/30/2001---

" 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. 
...Matthew Burbridge Hewlett Packard, Bristol Telnet: 312 7010 E-mail:
[email-masked] "

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 12 Jun 2002 13:23:12 -0700 (PDT)

> FirstBurstSize, before it waits for a R2T from the target?

No. See the note I sent which crossed this one in the mail.

If the initiator doesn't set the F bit in the command PDU (and
InitialR2T=No), then it indicates that it will act as if it has already
received an R2T for up to FirstBurstSize worth of the data.

However the initiator can CHOOSE to set the F bit, and then it will send
no more data until it receives an R2T.

> them only make the spec more complex.

How big do you think FirstBurstSize and MaxRecvPDUDataSize will be? The
defaults are 64k and 8k respectively. So with InitialR2T=No and default
numbers, 8 PDUs worth of data can be sent w/o need for an R2T, whereas
with just immediate data, only 1 PDUs worth of data won't need to wait.

While I don't have a histogram of typical i/o sizes (and even that would
be OS and task-set specific), I expect that a good number will be in the
8k to 64k range. So unsolicited data permit writes of those sizes to not
need to wait for the target to send an R2T.

Take care,

Bill