Re: iSCSI : Command Ordering Proposal.

[julian_satran@il.ibm.com]

Santosh,

The only puzzling question is what kind of digest error would you detect
for a command that the target has not yet started acting upon? This assumes
out of order delivery to SCSI right?  And even then if the task is
recognized you could use a CmdSN of 0 as the command is clearly active.

Only for commands that never gave a sign "of life" you have to use the
original CmdSN in case the command did not make it to the delivery queue.

Julo

Santosh Rao <santoshr@cup.hp.com> on 30/01/2001 09:58:47

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   matt_wakeley@agilent.com
cc:   ips@ece.cmu.edu (IPS Reflector)
Subject:  Re: iSCSI : Command Ordering Proposal.




Matt,

Comments in-line.

Regards,
Santosh

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

The above was stated to explain why "retry" commands need
to use CmdSN [and cannot use a CmdSN of 0 as you were
proposing].

The problem being originally described can occur when the
initiator applies a "discard & retry" policy on detecting
a digest error at its end. In such a case, it would
"retry" the command, and if the CmdSN was not yet
acknowledged, would send the "retry" with the original
CmdSN.

Since the target continues to send PDUs to the initiator,
it can update the ExpCmdSN causing the "retry" to be
discarded by the target, because its CmdSN has slid
behind the window.

The spec does not mandate that an update to ExpCmdSN
MUST accompany the Data PDUs for a command. IOW, a target
may lag behind in updates to ExpCmdSN while continuing to
send Data PDUs for the received command.

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

Not when targets detect a digest error. Section 5.5 mandates targets
to send a REJECT with a reason of digest error. The "discard & retry"
policy is for initiators.

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

--
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
#################################