SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iscsi : X bit in SCSI Command PDU.


    • To: IPS Reflector <ips@ece.cmu.edu>
    • Subject: iscsi : X bit in SCSI Command PDU.
    • From: Santosh Rao <santoshr@cup.hp.com>
    • Date: Fri, 05 Oct 2001 16:56:25 -0700
    • Content-Transfer-Encoding: 7bit
    • Content-Type: text/plain; charset=us-ascii
    • Organization: Hewlett Packard, Cupertino.
    • Sender: owner-ips@ece.cmu.edu

    All,
    
    With the elimination of command relay from iscsi [in the interests of
    simplification ?], I believe that the X bit in the SCSI Command PDU can
    also be removed. As it exists today, the X bit is only being used for
    command restart, which is at attempt by the initiator to plug a
    potential hole in the CmdSN sequence at the target. It does this on
    failing to get an ExpCmdSN ack for a previously sent command within some
    timeout period.
    
    Given the above usage of command restart, no X bit is required to be set
    in the SCSI Command PDU when command re-start is done. 
    
    Either :
    (a) the target had dropped the command earlier due to a digest error, in
    which case, the command restart plugs the CmdSN hole in the target.
    
    [OR]
    
    (b) the target had received the command and was working on it, when the
    initiator timed out too soon and attempted a command restart to plug
    [what it thought was] a possible hole in the CmdSN sequence.
    
    In case (a), no X bit was required, since the target knows nothing of
    the original command. In case (b), no X bit is required again, since the
    (ExpCmdSN, MaxCmdSN) window would have advanced and the target can
    silently discard the received retry and continue working on the original
    command received.
    
    Removal of the X bit in the SCSI Command PDU has the following benefits
    :
    
    a) The CmdSN rules at the target are simplified. No need to look at X
    bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) window.
    
    b) The reject reason code "command already in progress" can be removed.
    There's no need for this reject reason code anymore, since X bit itself
    is not required, and the targets can silently discard commands outside
    the command window and continue to work on the original instance of the
    command already being processed at the target.
    
    c) Less work for the target and less resources consumed since it no
    longer needs to generate a Reject PDU of type "command in progress". It
    can just silently discard any command PDU outside the (ExpCmdSN,
    MaxCmdSN) window.
    
    d) Less code for the target, since it does not need :
    - any Reject code paths when it receives X bit command PDUs that are
    already in progress.
    - No special casing of CmdSN checking rules.
    - No overheads of verifying a received command based on its initiator
    task tag, to check if the task is currently active, prior to sending a
    Reject response with "command in progress".
    
    
    Comments ?
    
    Thanks,
    Santosh
    
    
    -- 
    ##################################
    Santosh Rao
    Software Design Engineer,
    HP-UX iSCSI Driver Team,
    Hewlett Packard, Cupertino.
    email : santoshr@cup.hp.com
    Phone : 408-447-3751
    ##################################
    


Home

Last updated: Sat Oct 06 14:17:25 2001
7092 messages in chronological order