SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: AHS drop bit



    Julian,
    
    > We don't have any use for it but some "vendor specific" extensions may.
    
    That then begs the question - should/can we anticipate vendor-specific needs
    and provide for them in the spec?
    
    My preference is to do away with AHS drop bit - since it doesn't seem
    useful to either iSCSI or SCSI.
    
    Regards.
    --
    Mallikarjun
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    Hewlett-Packard MS 5668
    Roseville CA 95747
    
    ----- Original Message -----
    From: "Julian Satran" <Julian_Satran@il.ibm.com>
    To: <ips@ece.cmu.edu>
    Sent: Saturday, January 05, 2002 6:10 AM
    Subject: Re: iSCSI: AHS drop bit
    
    
    > Mallikarjun,
    >
    > The bit was really meant to enable dropping the additional header and not
    > the whole request if ignored but rejecting the whole request.
    > We don't have any use for it but some "vendor specific" extensions may.
    >
    > I suggest we change the wording of non-ISCSI non-iSCSI/vendor specific
    >
    > Julo
    >
    >
    >
    >                     "Mallikarjun
    >                     C."                  To:     ips <ips@ece.cmu.edu>
    >                     <cbm@rose.hp.c       cc:
    >                     om>                  Subject:     iSCSI: AHS drop bit
    >                     Sent by:
    >                     owner-ips@ece.
    >                     cmu.edu
    >
    >
    >                     14-12-01 22:48
    >                     Please respond
    >                     to cbm
    >
    >
    >
    >
    >
    > Julian,
    >
    > Section 3.2.2.1 says the following on the AHS drop bit -
    >            bit 7 - Drop Bit - if set to 1 this AHS may be ignored if not
    >            understood; if set to 0 this AHS must be rejected if not
    >            understood.
    >
    > - I suspect it is the entire command that was meant to be failed, not
    >   just the AHS...
    >
    > - If it is a SCSI operation that is being failed, I suggest that
    >   the target should end the command with an appropriate SCSI CHECK
    >   CONDITION - so the command sequence window can advance at the
    >   transport level (and the inability of the target to support say
    >   extended CDB is known end-to-end, to prevent fruitless SCSI retries).
    >
    > - This bit may be useful for AHS code "Non-iSCSI extensions", but
    >   I could not see how it can be used for the defined iSCSI operations.
    >   If it is indeed so, I would actually suggest dropping this feature.
    >
    > Regards.
    > --
    > Mallikarjun
    >
    >
    > Mallikarjun Chadalapaka
    > Networked Storage Architecture
    > Network Storage Solutions Organization
    > MS 5668         Hewlett-Packard, Roseville.
    > cbm@rose.hp.com
    >
    >
    >
    >
    >
    
    


Home

Last updated: Tue Jan 08 15:17:52 2002
8314 messages in chronological order