Re: iSCSI : Command Ordering Proposal.

[Matt Wakeley <matt_wakeley@agilent.com>]

Douglas Otis wrote:
> 
> 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.

You are wrong.  It specifically states in the document in 1.2.2.1:

"CmdRNs are significant only during command delivery to the target.
Once the device serving part of the target SCSI has received a
command, CmdRN ceases to be significant."

Any resources the target allocates must be based on the task tag.

-Matt



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