SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: DataPDUInOrder=No Clairification



    In addition to what Julian just said -
    
    iSCSI targets may choose to process inbound Data PDUs
    and track missing DataSNs to issue recovery R2Ts, regardless
    of the negotiated value of the DataPDUInOrder key.  This
    key negotiates the relationship between DataSNs and their
    Buffer Offset values and thus is orthogonal to recovery.
    --
    Mallikarjun
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions
    Hewlett-Packard MS 5668
    Roseville CA 95747
    cbm@rose.hp.com
    
    ----- Original Message -----
    From: "Julian Satran" <Julian_Satran@il.ibm.com>
    To: "Nicholas A. Bellinger" <nick@pyxtechnologies.com>
    Cc: "Andre Hedrick" <andre@pyxtechnologies.com>; "David Black" <Black_David@emc.com>; "Mallikarjun
    Chadalapaka" <cbm@rose.hp.com>; "IPS MailingList" <ips@ece.cmu.edu>
    Sent: Wednesday, May 21, 2003 4:38 AM
    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>
    > >
    >
    
    


Home

Last updated: Wed May 21 23:19:18 2003
12596 messages in chronological order