RE: iscsi: unsolicited data question

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Wed, 12 Jun 2002, Julian Satran wrote:

> 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.

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. :-)

>         To:     Julian Satran/Haifa/IBM@IBMIL
>         cc:     ips@ece.cmu.edu, owner-ips@ece.cmu.edu
>         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?

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