Ø
Sequence 0: Offsets:
65536->98304
> Sequence 1: Offsets: 32768->65536
> Sequence 2: Offsets: 98304->131072
> Sequence 3: Offsets: 0->32768
This shows overlap of offsets 98304, 65536 and 32768. Did you intend
for that to be part of the example?
Eddy
-----Original Message-----
From: Julian Satran
[mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, May 21, 2003 7:39 AM
To: Nicholas A. Bellinger
Cc: Andre Hedrick; David Black;
Mallikarjun Chadalapaka; IPS MailingList
Subject: Re: iSCSI: DataPDUInOrder=No
Clairification
Dear Nicholas,
"Nicholas
A. Bellinger" <nick@pyxtechnologies.com> wrote on 21/05/2003 12:48:15:
> [This is a resend due to mailer problems,
please excuse any duplicates.]
>
> Greeting all,
>
> I am inquiring about the
author's intent and proper usage of
> DataPDUInOrder=No. Of course the
definition of the aforementioned
> parameter is defined in section 12.18:
>
> "No is used by iSCSI to indicate that
the data PDUs within sequences
> can be in any order."
>
> I had originally used the interpretation that
it was mainly designed to
> aid within-command recovery in the following
DataOUT (not excluding
> DataIN) example:
>
> When a DataOut PDU fails a Data Checksum,
DataPDUInOrder=No allows the
> target to continue to receive the rest of the
DataOut sequence without
> having to discard PDUs received after the
initial failure. Hence,
> the Recovery R2T only has to contain Failed
Offset + Failed PDU Length.
>
> This compared to the same example with
DataPDUInOrder=Yes:
>
> When a DataOut PDU fails a Data Checksum,
DataPDUInOrder=Yes requires
> the target to NOT acknowledge the any futher
PDUs in the DataOut
> sequence until the initial failure is
recovered. Hence, the Recovery
> R2T must contain Failed Offset -> Length
to end of Sequence.
>
> This type of example seems like the most
logical application of
> DataPDUInOrder=No, that is one assumes the
pdus in a given sequence will
> be still sent in increasing order. If
an error occurs one is allowed to
> continue to receieve pdus out of order and
request only the missing
> ones.
>
> Now let us consider another more unorthadox
(and perhaps a bit
> illogical) example:
>
> Consider a DataOUT Sequence of 32k,
interpreting the definition in
> section 12.18 can one assume the following is
legal?
>
> Initiator -> Target
>
> DataSN: 0, Offset: 24576, Length: 8192
> DataSN: 1, Offset: 0, Length: 8192
> DataSN: 2, Offset: 16384, Length: 8192
> DataSN: 3, Offset: 8192, Length: 8192
>
This is
indeed legal
> This type of example assumes the pdus in a
given sequence may be sent in
> any order, and the target handles the
metadata for each pdu. If this is
> indeed legal, then its safe to assume the
following 128k DataIN example
> for DataSequenceInOrder=No is legal as well:
>
> Target -> Initiator
>
> Sequence 0: Offsets: 65536->98304
> Sequence 1: Offsets: 32768->65536
> Sequence 2: Offsets: 98304->131072
> Sequence 3: Offsets: 0->32768
>
> My guess is these both are indeed legal.
>
Yes they are
legal.
The stricter
sequencing requirement is not there to avoid recovery but rather to enable
devices to optimize
transmission
in face of "mechanical" delay and lack of resources.
> Thanks,
> --
> Nicholas A. Bellinger
<nick@pyxtechnologies.com>
>
