Re: iSCSI : Command Ordering Proposal.

[Santosh Rao <santoshr@cup.hp.com>]

Doug,

I'm not sure if we are speaking the same issue here. Can you
please elaborate further on your concerns. 

The handshake being discussed by me does NOT have to do with
freeing resources. It is a handshake b/n the target & 
initiator on the CmdSN/ExpCmdSN, so that "retry" commands
from initiator to target remain with the (ExpCmdSN, MaxCmdSN)
window.

Resources at the target end are de-allocated when it receives
an ExpStatSN for the StatSN. (IOW, resource de-allocation has 
to do with StatSN ACKs from the initiator, not CmdSN).
If a target were not to implement status recovery, resource
de-allocation can occur once a TCP ACK is received for the 
SCSI Response PDU. (if a mechanism were to exist to identify
that all the octets that constitute the Status PDU have been
ACK'ed.)

This also brings up an interesting issue which is :

If the target needs to hold onto its status PDU until at least
the TCP ACK is received for all of the bytes that constitute
the PDU and there is no easy mechanism to associate b/n
a TCP ACK and all bytes of the Status PDU being ACK'ed,
the simplest approach becomes de-allocation of status &
I/O resources based on ExpStatSN. 

If that is the case, the spec should change 
"targets MAY implement status recovery"
to "targets MUST hold onto status PDU until ExpStatSN" update
is received.

Regards,
Santosh

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


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