Re: iSCSI: CmdSN during the Login phase

["Robert D. Russell" <rdr@mars.iol.unh.edu>]

> If you use the next in line CmdSN for the session, you block all the SCSI
> commands the existing connections are sending while negotiating this new
> connection.
> 
> -Matt
> 


I don't understand how the new negotiation blocks the existing connections
in this case.  The login negotiation involves exchanges of login, text
commands, text responses and login responses that all share the same
Initiator Task Tags, but NOT the same CmdSN -- each new command in this
negotiation process carries a new CmdSN, and other connections can get
their own CmdSN values without waiting for the full negotiation process
to complete.

Consider the following:

1. The TCP connection is established completely "in parallel" to the
   existing connections and has no effect on them.

2. If IPsec or other non-iSCSI security is being used, it is negotiated
   "in parallel" to the existing connections and has no effect on them.

3. The initiator now needs to send the login on the new connection, and
   for that it selects the "next" CmdSN, increments it by 1, and sends
   the login command.  The next command on any other connection will
   use the incremented CmdSN and increment it in turn, etc.  This command
   can still be sent on the other connection.  It is true that the target
   cannot process this other command until the target has sent the first
   login response to the login command (because of the sequencing imposed
   by the CmdSN).  However, the other connection is NOT blocked during the
   complete login negotiation phase, because each subsequent text command
   sent by the initiator uses the next CmdSN and is processed by the
   target AFTER any intervening commands on other connections.

   The commands in the login negotiation all have the same
   Initiator Task Tag, but not the same CmdSN.  Therefore they do not
   prevent other connections from consuming CmdSN values.  In fact, it is
   possible for several logins for additional connections to be going on
   simultaneously while commands are still flowing (and being processed)
   on the existing connections.

   Of course, the time needed by the target to process login and text
   commands should be kept to a minimum, which just reinforces the need
   to simplify the login negotiation process as much as possible.

Bob Russell