SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: Bidirectional SCSI commands and iSCSI



    
    Jim Hafner,
    Since one of the things we are trying to do is not stray too far from the
    CDB structure which FC uses, do you or anyone else on the list know how FCP
    is structuring their CDB for this feature?
    
    .
    .
    .
    John L. Hufferd
    
    
    julian_satran@il.ibm.com@ece.cmu.edu on 10/02/2000 11:02:29 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: Bidirectional SCSI commands and iSCSI
    
    
    
    
    
    Jim,
    
    I'll take a look at the proposals (I assume they are on the T10 site).
    My concern about cluttering is related to the attempt to make a
    fixed-length header
    as I think that software initiators will be widely used and they are far
    more efficient with fixed length headers for widely used operations.
    
    Thanks,
    Julo
    
    "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> on 02/10/2000 18:22:40
    
    Please respond to "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:
    Subject:  Re: Bidirectional SCSI commands and iSCSI
    
    
    
    
    
    Julo,
    
    True, those examples are not true duplex operations. These are only the
    current thinking or motivation for bi-directional commands.  They are not
    the end of the story, I'm sure.
    
    However, the only SAM-2 requirement on bi-directional commands (as now
    defined) is that DataOut buffer be ready at the time the command is issued
    (so the target can get/request that data at any time after receipt of the
    command).  In other words, the content of the DataOut buffer should not be
    time or data-dependent on the contents of the DataIn buffer.  This means
    that as far as SAM-2 is concerned, there is no problem with a true duplex
    operation.  (We just don't have any examples at the moment.)
    
    I think your second proposal (using "immediate" data) is only attempting to
    address the specific examples (OSDs), and not the generic notion of
    bi-directional commands.  How would that solution work if the DataOut
    buffer was a 1MG chunk of user data for a XDREADWRITE command?
    
    The first method (splitting, if I read it correctly) undercuts the
    motivation that is generating this bi-d command in the first place. The
    SCSI layer could do that as well, but the issue is one of atomicity of
    command.  (Aside: one principle governing definitions of bi-directional
    commands in T10 is that there must always be a two (or more)
    uni-directional variant of the command, to allow a complex operation to be
    performed on a traditional uni-directional with simpler steps. I read your
    suggestion as having iSCSI do this for the SCSI layer -- there'd be no
    point.  Besides, doesn't this break layering?).
    
    Finally, I would suggest a look at the FCP-2/3 proposal just submitted. I
    think they are proposing (for legacy reasons) a new IU for bi-directional
    commands.  If you're concerned about cluttering your header, then this
    group might think about adding a new PDU for these types of commands.
    
    I don't quite understand the reluctance to add new fields in the header for
    this purpose.  The current design is not yet cast in stone and now is the
    perfect opportunity to get it defined in a way that accomodates the future
    that T10 seems to be moving (rapidly) towards.
    
    Jim Hafner
    
    
    julian_satran@il.ibm.com@ece.cmu.edu on 10-01-2000 12:16:06 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: Bidirectional SCSI commands and iSCSI
    
    
    
    
    
    Jim,
    
    Both the examples you gave have something peculiar - the operations are to
    executed really in sequence (we are no talking about full duplex I/O
    operations?).
    I any case, in order no to extend excessively the headers we can either
    introduce
    a "next header" field (as in IP V6) or split the operation at the iSCSI
    level into
    two phases - each carrying its parameters and each ended with a status -
    
    like:
    
      - out XOP1, XOP2, OD1,
      -in S1, ID, S2
    
    
    
    In any case commands having only a parameter set (fixed or variable) - like
    those
    for the object disk should be handled with the parameters sent as immediate
    data
    (as with the three party commands) - parameter size will probably be
    limited
    and the performance requirement will be similar to those of block
    read/write.
    Do we need for those to care also about residual counts for parameters?
    
    
    Julo
    
    "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> on 29/09/2000 00:21:32
    
    Please respond to "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   ips@ece.cmu.edu
    Subject:  Re: Bidirectional SCSI commands and iSCSI
    
    
    
    
    
    Julo,
    
    The primary motivation is for object-based storage devices (OSDs).  The
    protocol that seems to be needed in that environment is the ability to send
    a  CDB, plus some parameter data (DataOut) AND get back read-type data
    (DataIn) in the same command sequence.
    
    One (non-OSD) command has been proposed in T10 for an XOR type XDREADWRITE
    command.
    
    SAM-2 has now allowed for such commands in the architecture. From this
    perspective, it is completely symmetric. Transports that support this
    feature will need to have data structures in there PDUs or IUs (or
    whatever) to indicate things like DataOut datalength, DataIn datalength,
    possible virtual addresses for each buffer, etc.  In other words, there
    will potentially be two active buffers (on each end) for use with the same
    command.    So, e.g., iSCSI PDU may need to have both "DataIn expected data
    transfer length" and  "DataOut expected transfer length" fields.  I'm
    assuming that the data direction in the existing iSCSI PDU is derived from
    the SCSI opcode, unlike FCP where there are fields to indicate the data
    direction.  (I am surprised not to find such things in the iSCSI Command
    PDU.)
    
    There are two proposals in T10 to enable this feature in SPI-4 and in FCP-x
    (probably FCP-3).
    
    Jim Hafner
    
    
    julian_satran@il.ibm.com@ece.cmu.edu on 09-28-2000 12:10:53 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: Bidirectional SCSI commands and iSCSI
    
    
    
    
    
    Jim,
    
    What is the intended use?  Are there already commands that use it?
    Is there a major/minor distinction - like output data & input results or
    output
    parameters & input data - or is it intended to be completely symmetric?
    
    Julo
    
    "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> on 20/09/2000 17:56:27
    
    Please respond to "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com>
    
    To:   ips@ece.cmu.edu
    cc:    (bcc: Julian Satran/Haifa/IBM)
    Subject:  Bidirectional SCSI commands and iSCSI
    
    
    
    
    Folks,
    
    In case you missed this, T10 just approved changes to SAM-2 (rev14) which
    remove the restriction that a single SCSI command can have a data flow in
    only one direction (DataIn xor DataOut).   Transport specs (that want to
    allow this) will need to change to allow for two sets of Data buffer fields
    in the headers (length, over/underrun, etc.).
    
    Is anybody looking to modify the iSCSI spec to get these concepts
    supported?
    
    Jim Hafner
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:06:54 2001
6315 messages in chronological order