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

["Douglas Otis" <dotis@sanlight.net>]

David,

Ver 5 Page 11:

   "The iSCSI target layer MUST deliver the commands to the SCSI target
   layer in the order specified by CmdSN."

I am not making an assumption about there being a CmdSN sequence function.
It is a MUST within the proposal!  Yes, you can bridge holes within CmdSN
sequence using pointers and that would be expected and I described this as a
list.  This list still must be sorted between sequential and immediate
especially when multiple connections are used to determine a next in
sequence.  You would not want the creation of these lists to be blocking
until the next in sequence is seen as you seem to imply.  You view this as a
pointer list, again I agree.  The use of rejection still greatly simplifies
this process.  You are wrong about the use of CmdSN being limited to just
the flow control window.

To not support rejects, you are then relying on the target to handle these
now out of sequence commands.  In addition, that there be spare overhead
allotted to handle these undetermined number of "immediate" commands.  You
will then also not see any immediate acknowledgement of these "immediate"
commands sent to the target unlike ALL other such commands.

Can you answer how many "immediate" commands are allowed?  When would you
expect these "immediate" commands to be acknowledged to allow more such
commands?

Doug

> 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
> ---------------------------------------------------
>
>
>