Re: iSCSI : Command Ordering Proposal.

[Matt Wakeley <matt_wakeley@agilent.com>]

Santosh Rao wrote:
> 
> Matt Wakeley wrote:
> 
> > Retried commands should have already been queued and/or executed.
> 
> Not necessarily. A TCP connection failure can affect the command PDU.

In which case the target will have "silently discarded" the PDU.  Then, it
will not acknowledge via ExpCmdSN any commands past the err'd command, so the
initiator can resend the command with the same CmdSN and enabling command
delivery to SCSI to continue.

> Similarly, the target may have detected a header or data digest error
> on the SCSI Command PDU, sent a REJECT

I thought any digest errors are silently discarded - therefore, there is no
reject.  Nevertheless, the ExpCmdSN is not incremented (as stated above), and
the initiator can then resend that command with the same CmdSN.

-Matt

> and the initiator would have "discarded and retried" the task.
> 
> In both of the above cases, the command is not queued and/or being executed
> at the target.
> 
> Such commands, when retried, need to enforce ordering. Hence, the need to
> specify CmdSN in the "retry", if the CmdSN is yet to be acknowledged.
> The difficulty lies in the establishment of a "sync point" with the ExpCmdSN,
> prior to the initiation of these "retry" commands, so as to ensure that the "retry"
> will not be discarded by the target, because the CmdSN slid behind the
> (ExpCmdSN, MaxCmdSN) window.
> 
> The ExpCmdSN in the login response provides this "sync point" during connection
> failure recovery. The problem is only with digest error "retries".
> 
> If one were to NOT apply the "discard and retry" policy on a header digest error,
> [under the assumption that the I.T.T cannot be trusted on a header digest error],
> the problem further reduces to the following cases :
> 
> a) data digest error detected by a target on a command PDU. (immediate data).
> b) data digest error detected by an initiator on inbound Data PDUs of a READ
> I/O, and the CmdSN for the command is yet to be acknowledged, but an ACK
> may be in-flight behind the Data PDU.
> 
> Regards,
> Santosh
> 
> > 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:
> >
> > >
> > > 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