RE: iSCSI : Command Ordering Proposal.

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

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.

One could view CmdSN as Client Sequence Number and StatSN as Server Sequence
Number where these change to CSN and SSN. :)  This gets away from the
duplexed meaning of the number as defined for CRN.  With the task attribute
and to be sure of the sequence number, there is little gained from the use
of CmdSN = 0 as an exception.  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.

Doug

> Charles Binford wrote:
>
> > Seems to me like adding a new CRN field for command ordering (if the
> > application so chooses) and re-defining the CmdRN field to only
> provide the
> > flow control satisfies the requirements without overloading the
> > functionality of a single field.
> >
>
> This is exactly my point. Strict ordering should only be enforced when
> driven by an application. (either through the use of Ordered Task Tags for
> task set ordering or the use of CRN for end-to-end ordering).
>
> The use of CmdSN to order all commands seems an over-kill when those
> applications that did need ordering would use the Ordered Task Tag or
> CRN, based on their need.
>
> Strict ordering is only required for the aborts that follow their
> commands.
>
> Also, it would be helpful to re-name the new 1-byte CmdRN in the
> new iSCSI PDU to CRN to avoid confusion with the old semantics of
> CmdRN. (which is now the CmdSN !!)
>
> Regards,
> Santosh
>