Subject: RE: iSCSI:flow control, acknowledgement, and a deterministic reco very

From: [email-masked]
Date: Mon, 9 Apr 2001 11:30:02 -0400

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
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 9 Apr 2001 11:06:46 -0700

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