Re: iscsi : X bit in SCSI Command PDU.

["Julian Satran" <Julian_Satran@il.ibm.com>]

Santosh,

I am not sure you went through all scenarios. A conversation with your colleague - Mallikarjun - and getting through the state table may go a long way to clarify the need for X.

And I am sure that by now you found yourself several .

Julo

Santosh Rao <santoshr@cup.hp.com> Sent by: owner-ips@ece.cmu.edu 06-10-01 01:56 Please respond to Santosh Rao

To:        IPS Reflector <ips@ece.cmu.edu>         cc:                 Subject:        iscsi : X bit in SCSI Command PDU.

All,

With the elimination of command relay from iscsi [in the interests of
simplification ?], I believe that the X bit in the SCSI Command PDU can
also be removed. As it exists today, the X bit is only being used for
command restart, which is at attempt by the initiator to plug a
potential hole in the CmdSN sequence at the target. It does this on
failing to get an ExpCmdSN ack for a previously sent command within some
timeout period.

Given the above usage of command restart, no X bit is required to be set
in the SCSI Command PDU when command re-start is done. 

Either :
(a) the target had dropped the command earlier due to a digest error, in
which case, the command restart plugs the CmdSN hole in the target.

[OR]

(b) the target had received the command and was working on it, when the
initiator timed out too soon and attempted a command restart to plug
[what it thought was] a possible hole in the CmdSN sequence.

In case (a), no X bit was required, since the target knows nothing of
the original command. In case (b), no X bit is required again, since the
(ExpCmdSN, MaxCmdSN) window would have advanced and the target can
silently discard the received retry and continue working on the original
command received.

Removal of the X bit in the SCSI Command PDU has the following benefits
:

a) The CmdSN rules at the target are simplified. No need to look at X
bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) window.

b) The reject reason code "command already in progress" can be removed.
There's no need for this reject reason code anymore, since X bit itself
is not required, and the targets can silently discard commands outside
the command window and continue to work on the original instance of the
command already being processed at the target.

c) Less work for the target and less resources consumed since it no
longer needs to generate a Reject PDU of type "command in progress". It
can just silently discard any command PDU outside the (ExpCmdSN,
MaxCmdSN) window.

d) Less code for the target, since it does not need :
- any Reject code paths when it receives X bit command PDUs that are
already in progress.
- No special casing of CmdSN checking rules.
- No overheads of verifying a received command based on its initiator
task tag, to check if the task is currently active, prior to sending a
Reject response with "command in progress".


Comments ?

Thanks,
Santosh


-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################