Re: iSCSI : Command Ordering Proposal.

[Matt Wakeley <matt_wakeley@agilent.com>]

Retried commands should have already been queued and/or executed.  The goal of
the retry is simply to replay back to the initiator the results of the
execution. Therefore, there is no ordering requirement for "retried" commands
and CmdSN should always be zero.

-Matt

Santosh Rao wrote:
> 
> Douglas Otis wrote:
> 
> > Santosh,
> >
> > If there is a task attribute, the complexity is when you allow CmdSN = 0;
> >
> > Perhaps CmdSN = 0 should not be allowed or treated as just another in the
> > sequence.
> 
> The (CmdSN==0) does have its uses. One example is the use of NOP-OUT for
> a "connection ping."
> 
> >  If a retry flag is set, the CmdSN below the
> > ExpCmdSN should be viewed as an exception much as Head of Queue should be an
> > exception for MaxCmdSN.  Both of these cases imply exceptional behavior by
> > the initiator in response to a problem.
> 
> Accepting a command outside the (ExpCmdSN, MaxCmdSN) window with the retry
> bit set then opens up windows for other types of stale and duplicate commands
> to be
> processed.
> 
> Here's the deal (as I view it) :
> 
> Commands are sent with the "retry" bit under 2 conditions :
> - Connection Failures
> - Digest Errors
> 
> In both these cases, an explicit handshake is required regarding the
> (ExpCmdSN, MaxCmdSN) window, prior to starting to send "retry"
> commands. This ensures that genuine "retry" commands do not slip
> behind the (ExpCmdSN, MaxCmdSN) window.
> 
> In the case of a connection failure, the Logout Response provides this
> handshake. For digest errors, there is no such hand-shake.
> Hence, a command that encountered a digest error and was retried could
> likely slip behind the (ExpCmdSN, MaxCmdSN) window and then be never
> processed.
> 
> Regards,
> Santosh