Subject: iSCSI - Change Proposal X bit

From: "Julian Satran" <[email-masked]>
Date: Tue, 23 Oct 2001 21:41:46 +0300

Dear colleagues,

A while ago Santosh Rao suggested on this list to remove the X bit as the 
reassignment function is now handled by a Task Management and "delayed" 
PDUs can be caught be the command window check.

The clear advantage of this change is that the target does not have to 
check for the X bit and may drop the command if it is out of the window or 
exists already.

However in order to drop "old" commands that might in the pipe on a 
sluggish connection - removing the X bit will require the initiator to 
issue an immediate NOP requiring a NOP response on every open connection 
whenever CmdSN wraps around (becomes equal to InitCmdSN).

We may want the new BHS to look like

Byte /    0       |       1       |       2       |       3       |
   /              |               |               |               |
  |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|  
  +---------------+---------------+---------------+---------------+
 0|I| Opcode      | Opcode-specific fields                        |
  +---------------+---------------+---------------+---------------+
 4|TotalAHSLength | DataSegmentLength                             |
  +---------------+---------------+---------------+---------------+
 8| LUN or Opcode-specific fields                                 |
  +                                                               +
12|                                                               |
  +---------------+---------------+---------------+---------------+
16| Initiator Task Tag or Opcode-specific fields                  |
  +---------------+---------------+---------------+---------------+
20/ Opcode-specific fields                                        /
 +/                                                               /
  +---------------+---------------+---------------+---------------+
48

and move the direction bit in the opcode 1 bit up

Alternatively we may make the X bit reserved.

Comments?

Julo

---

From: Santosh Rao <[email-masked]>
Date: Tue, 23 Oct 2001 13:50:59 -0700

> whenever CmdSN wraps around (becomes equal to InitCmdSN).

Julian,

Can you please explain further the corner case you are describing above
? Are you suggesting that special action should be taken every time
CmdSN wraps around, in case there were holes in the CmdSN sequence at
the wrap time ? Why is that ?

Here's my understanding of how this plays out :

Rule 1) 
The CmdSN management rules at the target should be handling CmdSN wrap
case and the initiator cannot issue more than 2^32 -1 commands beyond
the last ExpCmdSN update it has received from the target, since the
target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above
the last ExpCmdSN. (per Section 2.2.2.1)

Rule 2)
Any holes that occur in the CmdSN sequence are attempted to be plugged
by the initiator by re-issuing the original command. If the CmdSN never
got acknowledged and the I/O's ULP timeout expired, the initiator MUST
perform session recovery. (per Section 8.6)

Thus, going by the above 2 rules, if the CmdSN sequence wraps upto
ExpCmdSN, the initiator will not be able to issue further commands,
since the target will keep the CmdSN window closed. The window can only
re-open when the CmdSN holes are plugged allowing ExpCmdSN and thereby,
MaxCmdSN to advance.  (rule 1 above).

Under the above circumstances, the initiator will possibly try to plug
the CmdSN hole by re-issuing the original command. It may do this 1 or
more times before its ULP timeout expires. Either the holes get plugged
and the windoe re-opens, or ULP timeout occurs without the corresponding
CmdSN for that I/O having been acknowledged, resulting in session
logout. (rule 2 above).

What is required over and beyond the above ? Why does removal of X-bit
require an immediate NOP to be issued every time CmdSN wraps and a hole
exists in the CmdSN sequence (??). 

Regards,
Santosh

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: Santosh Rao <[email-masked]>
Date: Tue, 23 Oct 2001 14:22:13 -0700

> case and the initiator cannot issue more than 2^32 -1 commands beyond
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^
The above should read " more than 2^31 - 1 commands beyond ......."