RE: iSCSI: Flow Control

[julian_satran@il.ibm.com]

Somesh,

You are just describing an implementation.

As commands are but a small part of the load you can post a large enough
number
to each NIC or have the NICs grab them from a pool (and marking them
in-use) through
a bus transaction.

Julo

"GUPTA,SOMESH (HP-Cupertino,ex1)" <somesh_gupta@am.exch.hp.com> on
11/10/2000 17:31:00

Please respond to "GUPTA,SOMESH (HP-Cupertino,ex1)"
      <somesh_gupta@am.exch.hp.com>

To:   Matt Wakeley <matt_wakeley@agilent.com>, IPS Reflector
      <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: Flow Control





> -----Original Message-----
> From: Matt Wakeley [mailto:matt_wakeley@agilent.com]
> Sent: Wednesday, October 11, 2000 4:39 AM
> To: IPS Reflector
> Subject: Re: iSCSI: Flow Control
>
>
> "GUPTA,SOMESH (HP-Cupertino,ex1)" wrote:
>
> > I agree. The only difference of opinion I have is whether the
> > credit/window should be on a per connection basis or a session
> > basis.
>
> Since the "commands" go across the various TCP connections,
> but ultimately
> end up in the same single command queue, what does command
> credit/window per
> TCP connection buy you?

Assuming that flow control is needed, the following are the
pros for per connection credit/window (I will assume multiple
NICs and also each connection on a session in a seperate NIC)

1. For the target - the target provides credit based among
other factors on the availability of command buffers. An
exclusive (at any instant in time) list of command buffers
will be posted to each NIC (to make sure that different NICs
do not overwrite each other). If the credit is per session, what
value of credit is given out (if credit can be adjusted
dynamically)? It is the credit per session, based on the
least number of buffers available for any given NIC?

2. For the initiator - Let us assume that all connections are
flow controlled due to running out of credit. Now the credit
is extended on one of the connections. In the credit per session
model, the new credit has to flow to the host, which can then
post additional commands on any of the connections in the
session. The host can also only post the commands to any
of the NICs that fall within the window. It has to queue up
all others in a seperate queue. In addition, the NIC will
have to interrupt the host so that the host processes
the credit/window indication.

   If the credit is per connection, then the host can post
available commands to each of the adapters using whatever
load balancing algorithms have been adopted. Then as credit
is available on each of the connections, the commands can be
transmitted.

   One of the side effects of this is that the commands may
not arrive at the target in the "session-wide" order i.e.
a connection is blocked and its commands are not going
through so a certain number of commands in a "session-wide"
command sequence did not get through or because a poor
load balancing algorithm was being used etc. I think these are
the serious side-effects of trying to do multiple connection
sessions - and similar nasty effects occour no matter what
algorithm for load balancing is attempted - connections can
always block or quality degrade throwing off the pacing of
the entire session.

>
> -Matt
>