Subject: RE: iSCSI: FirstBurstSize and unsolicited data

From: Eddy Quicksall <[email-masked]>
Date: Fri, 14 Jun 2002 16:42:56 -0400

The initiator should probably reduce FirstBurstSize to 8k.

Although the spec does not seem to mandate this.

Eddy

-----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
Sent: Friday, June 14, 2002 1:22 PM
To: Nandakumar Ramamurthy
Cc: [email-masked]
Subject: Re: iSCSI: FirstBurstSize and unsolicited data

On Fri, 14 Jun 2002, Nandakumar Ramamurthy wrote:

> Hi All,
>
> Consider the case where InitialR2T=yes and ImmediateData=yes.
> All other values are the defaults.
>
> The expected data transfer length for a SCSI write
> operation is a value exceeding FirstBurstSize (64KB).
>
> In the above case, the initiator will send immediate
> unsolicited data (MaxRecvPDULength=8192 bytes).
> After that it has to wait for an R2T from the target.

That is correct.

> In this scenario, FirstBurstSize of data will not be sent
> to the target as unsolicited data-out's cannot be sent here.
>
> My understanding is that the remaining data can be
> sent only through solicited Data-out PDUs,
> and this is the expected way according to the draft.
>
> What does the following statement(in Section 9.4.6.2 Sense Data) mean in
> this context ?
>
> <quote>
>
> The target reports the "Not enough unsolicited data" condition only
> if it does not support output (write) operations in which the total
> data length is greater than FirstBurstSize, but the initiator sent
> less than FirstBurstSize amount of unsolicited data, and out-of-order
> R2Ts cannot be used.
>
> </quote>

I think what that's getting at is if you do a write command and send
unsolicited data-out PDUs, you've promised to send FirstBurstSize worth of
data. If you don't, to continue the operation, the target needs to send an
R2T for the missing data. But that would be an out-of-order R2T since by
sending unsolicited data, you are acting as if you received an R2T for
FirstBurstSize data; this error R2T would be going backwards.

Take care,

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Fri, 14 Jun 2002 13:57:48 -0700 (PDT)

> Although the spec does not seem to mandate this.

Why? I don't see how that helps us (forcing it to be 8k, or
MaxRecvPDUDataSize), because immediate data are bounded by both
FirstBurstSize and MaxRecvPDUDataSize. i.e. we will always have to check
both.

So putting a requirement that FirstBurstSize not be over 8k (or
MaxRecvPDUDataSize) doesn't mean we can skip checking immediate data size
against both FirstBurstSize and MaxRecvPDUDataSize, but it means we would
need to add code to login to check this bounding. How does this help us?

Take care,

Bill