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



    In lieu of the requested translation ...
    
    > 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. 
    
    Doug is assuming that the sequencer that issues commands runs off of CmdSN.
    Needless to say, that's not necessary, as the sequencer could run off
    whatever
    it likes (e.g., pointers in memory).  If the sequencer runs off something
    internal
    instead of CmdSN, immediate commands don't cause "holes" in its sequence
    because the CmdSN-based "sequence" compresses them out as commands
    are released to the sequencer from the code that handles CmdSN-related
    state.
    
    As near as I can tell, the entire discussion of rejecting queued commands
    when an immediate command shows up is based
    on this implementation-specific assumption about not only the existence of
    a "sequencer" but also the use of CmdSN to implement it.  While those are
    valid ways to design a system, neither are necessary.  CmdSN tracking is
    only necessary in the portion of the system that generates the ExpCmdSN
    and MaxCmdSN responses and holds commands that have to wait for missing
    ones to show up.  An array-based implementation rather than a queue-based
    sequencer can handle this without the command rejection side-effects of
    Doug's envisioned sequencer, and there are doubtless more clever ways to do
    it.
    
    Unless someone other than Doug wants to speak up on the importance
    of a CmdSN-based sequencer implementation, I think discussion of that
    needs to be dropped, and changes beyond the use of an immediate
    flag instead of a zero CmdSN set aside as only being needed by this
    specific implementation and not of general applicability.  This includes
    Doug's latest message about commands being "rejected for replay at a
    new sequence".
    
    Thanks,
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
     
    
    


Home

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