SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI:flow control, acknowledgement, and a deterministic recovery



    Julian,
    
    If you do not reject commands pending within the sequencer, then you will
    need to log these out of sequence events to ensure the command taken out of
    sequence will not cause a hole later.  You could allow an exception for
    window size but if you are attempting to issue many of these urgent
    commands, then a single exception does not provide much flexibility.
    
    Should you reject all prior commands within the sequencer, there is no issue
    regarding the logging of these out of sequence commands.  Should there be a
    sequence of urgent commands, by flagging the first such command forces the
    window to be cleared to allow these urgent commands their immediate
    deployment.
    
    This rejection technique also has the advantage of deleting command holes
    without timeouts should there be a problem with a connection.  This
    technique supplemented with SNACK appears to provide a rather immediate
    recovery again without reliance on the SCSI layer.
    
    As there should already be code ready to handle rejected commands, using
    this mechanism does not add code and allows the transport to use this very
    simple mechanism.  This also does not depend on the target within the SCSI
    layer to handle these out of sequence events so there is less likelihood of
    needing the SCSI layer tailored to use iSCSI.
    
    While placing this immediate function into a flag ensures that such a
    command is acknowledged eventually if rejection is not used and immediately
    if commands are rejected, this flag however provides the vital information
    of command placement to prevent such a command from applying after
    subsequent commands for without this flag there is no assurance when such a
    command is received.
    
    Doug
    
    
    
    > The main reason for selecting 0 and not a flag for immediate delivery was
    > to enable immediate delivery even when the command window is closed.
    >
    > However we can achieve the same effect by using an immediate flag and
    > ausing the current CmdSN without advancing it.  With this we get a
    > reference to where in the stream the command where supposed to act if the
    > stream order is important. All commands that reached the target having
    > CmdSN less than the immediate CmdSN where sent before our command and all
    > those with a number equal or higher where sent after. Immediate commands
    > are the only ones that can have a CmdSN higher (by 1) that the allowed
    > window.
    >
    > Julo
    >
    >
    >
    
    


Home

Last updated: Tue Sep 04 01:05:08 2001
6315 messages in chronological order