Subject: RE: iscsi: unsolicited data question

From: "Julian Satran" <[email-masked]>
Date: Wed, 12 Jun 2002 20:18:49 +0300

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 12:38:47 -0700 (PDT)

> Neither bandwidth nor latency are wasted.

I'm agreeing with Julian, and commenting to Dennis. I don't find Dennis's
note in my ips mailbox; I either deleted it too fast, or Julian's arrived
before it. :-)

> Also, why do we need the unsolicited Data-out PDU feature when

To answer the last bit first, because you can burst out more PDU and
convey more data than just one PDUs worth.

Here's how I think about it. The initiator can, in principle, do one of
four things (negotiations after this):

1) Send no unsolicited data and no immediate data with the command PDU. In
this case, the F bit will be set, and the pdu's data length will be 0.
Also, the initiator is now waiting for an initial R2T starting at byte 0.

2) Send no unsolicited data but send immediate data with the command PDU.
In this case the F bit will be set, and the pdu's data length will be
non-zero. The initiator is waiting for an R2T starting just after the data
length.

3) Send unsolicited data but no immediate data with the command PDU. In
this case, the F bit is not set and the pdu's data length will be 0. The
initiator has just promised to send FirstBurstSize worth of data (up to
the command max of course). Any subsequent R2Ts will start after
FirstBurstSize.

4) Send unsolicited data and immediate data with the command PDU. In this
case, the F bit is not set, and the pdu's data length will be non-zero.
The initiator has just promised to send FirstBurstSize - pdu data len
worht of data in subseqent DATA-OUT pdus. Any subsequent R2Ts will start
after FirstBurstSize.

Initial negotiations will possibly rule out some of these choices. If
InitialR2T=Yes, options 3 & 4 go away. If ImmediateData=NO, options 2 & 4
go away.

The important thing though is that as soon as the target processes the
PDU, it knows which case it's in. It need not wait for future
transmissions to figure out what to do, as you were describing in your
question.

Take care,

Bill