Robert,
I think there should
be a restriction but it isn't as broad as requiring DataSequenceInOrder =
Yes.
The necessary and
sufficient requirements are (I think):
When immediate data
is sent, it MUST begin with the first byte of the data transfer -
rationale: there is no mechanism such as DataSN in the SCSI Command PDU to
indicate position of the immediate data so it must have an implied
position.
When unsolicited
non-immediate data is sent, there is an implied R2T for the first n bytes of
data
where n
= min(Expected Data Transfer Length, FirstBurstSize)
This implied R2T is
to be satisfied by the immediate data plus unsolicited SCSI Data-out PDUs. As
above, any immediate data must begin with the first byte of the data
transfer. If DataSequenceInOrder=No, then the data in the unsolicited SCSI
Data-out PDUs MAY be in any order but MUST be the bytes that satisfy
the implied R2T (that is, the first n bytes of the data).
rationale:
Since the R2T is implied, it doesn't have an explicit position and must have an
implicit position.
I don't think these
requirements are articulated in the draft.
Pat
I must
have missed something in the document. I did not see
any
restriction that required EMDP = 0 (or in iSCSI-ese, DataSequenceInOrder =
yes)
when
immediate data was transmitted. I would have expected
such
a
requirement. If that is not the case, then any data can be
transmitted
first
and any data can be requested with the first (overlapping) R2T, somewhat
confusing
the
issue.
If
someone can point me to that restriction, I would be
delighted.
Bob
Nandakumar,
There are no
restrictions on the amount of immediate data sent other than that it must be
less than MaxRecvDataSegmentLength and less than FirstBurstSize. So in the
conditions you have chosen, the initiator could send any amount of
ImmediateData from 4 Bytes to 8 KB. Doing so should not cause an error at the
target.
The purpose of
allowing an implicit InitialR2T is to gain efficiency by letting data start
flowing without having to wait a round-trip delay for an R2T. Gaining this
efficiency requires that the target know how much unsolicited data will be
sent when it receives the SCSI Command PDU so that it can immediately send the
first explicit R2T. The rule on sending the full FirstBurstSize (or all the
data) when unsolicited data is sent in Data-out PDUs achieves this. When the
target sees the SCSI Command PDU with the F bit set to 0, it knows that the
first data it needs to request with an R2T starts after FirstBurstSize
bytes.
When the SCSI
Command PDU has an F bit set to 1, then the target knows that
DataSegmentLength is the amound of unsolicited data being sent and it can
construct its first R2T. Therefore there is no reason to restrict the amount
of unsolicited data sent when only immediate data is sent (other than
that it not exceed the maximums).
That is what is
reflected in the rules.
Pat
Hi,
I have been following the discussion on this
thread.
I still have certain doubts regarding
the
conditions I specified in my original
mail.
The conditions are :
FirstBurstSize = 64KB
EDTL = 100KB ( EDTL >
FirstBurstSize)
MaxRecvDataSegmentLength = 8KB
ImmediateData = Yes
InitialR2T = Yes
In the above case the initiator cannot send
unsolicited Data-out PDUs.
Here unsolicited data(ImmediateData) < FirstBurstSize.
Will the target report any error in this case?
The modified text for Section 9.4.6.2 only refers to the
cases
where unsolicited Data-outs can be sent.
Please clarify if I am missing something very
obvious.
Thanks,
----- Original Message -----
Sent: Friday, June 21, 2002 11:41
AM
Subject: RE: iSCSI: FirstBurstSize and
unsolicited data
Eddy,
I
assume you meant EDTL not DSL and then the answer is yes and I again forgot
to subtract the immediate. A better formulation would be:
The target reports the "Incorrect
amount of data" condition if dur-ing data output the total data length to
output is greater than First-BurstSize and the initiator sent unsolicited
non-immediate data but the total amount of unsolicited data is different
than FirstBurst-Size. The target reports the same error when the amount of
data sent as a reply to an R2T does not match the amount requested.
Julo
| "Eddy Quicksall"
<Eddy@Quicksall.com>
06/21/2002 12:22 AM Please respond to "Eddy Quicksall"
|
To: Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:
RE: iSCSI: FirstBurstSize and unsolicited data
|
Isn't this saying that if DSL > FirstBurstSize, it would be
incorrect to send non-immediate unsolicited which is not equal to
FirstBurstSize?
The target reports the "Incorrect amount
of data" condition if dur-ing data output the total data length to output is
greater than First-BurstSize, but the initiator sent an amount different
than FirstBurstSize of unsolicited non-immediate data or the amount of data
sent as a reply to an R2T does not match the amount requested. Eddy
|