Re: iSCSI Autosense Consensus, Connection next steps

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

OK, you Sync and Async Fans, let me put up an Async strawman and I would
like to read your constructive comments (please leave out the comments that
say I am a flaming idiot for even suggesting this strawman).

Situation:
Client (Host) system has more then one NIC that supports at least TCP/IP
offload, and perhaps some parts of iSCSI.

Approach:
   Project to the upper layers -- "n" ports where "n" is the number of NICs
   Establish "n" sessions
   For each session, place one Command Stream TCP/IP connection on a  NIC
   No session's Command Stream is on a the same NIC as any other session
   For each session, place one Data Stream TCP/IP connection on each of the
   other NICs

Configuration Summary:
Each NIC supports one session's Command connection, and "n-1" Data
connections from other sessions.

Results:
The upper layers (SCSI drivers or Wedge drivers) will use the "n" ports as
they currently do today.  If the wedge drivers perform load balancing
today, they can do the same thing tomorrow with this configuration.  Data
can flow back on any of the NICs, any NIC that did not have the Command
Flow for a specific session.

Does this Configuration and Approach  make since?
----------------------------------------------------------------------------
Variant 1:
Project only one upper layer port, and perform a type of round robin
scheduling between the sessions (and thus the NICs).

Does this Configuration and Approach  make since?
----------------------------------------------------------------------------

Variant 2:
Project only one upper layer port, and perform a type of modified round
robin scheduling that forces all the commands for any specific LU to any
Session that has a current I/O, for that LU, in some way outstanding.  If
the LU has no other I/O outstanding, then place the I/O on any Session.

Does this Configuration and Approach make since?
---------------------------------------------------------------------------



.
.
.
John L. Hufferd