RE: iSCSI : Command Ordering Proposal.

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

Matt,

Whether you use the CmdSN or the tag to associate the retry, the CmdSN is
still used as a means to handshake freeing of resources and not the tag.  It
seems like a cleaner solution not to include exceptions on maintaining the
sequence just to allow this type of non-sequential use.  Clearly there is an
alternative that has benefits. Simply have the target allow exceptions based
on the command or task attribute and not drop the ability to handshake.  I
am aware of the present concept, but you did not speak about any downside to
this alternative.

Doug

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