RE: iSCSI: Flow Control

["GUPTA,SOMESH (HP-Cupertino,ex1)" <somesh_gupta@am.exch.hp.com>]

Julian,

> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: Wednesday, October 11, 2000 9:31 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: Flow Control
> 
> 
> 
> 
> Somesh,
> 
> You are just describing an implementation.

Yes I am trying to describe the synchronization pts and software
intervention caused by a session wide flow control model

> 
> 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.

First of all you really you have not addressed the target side
issues raised below. You describe two scenarios to alleviate the
initiator side problem

1. Post a large enough number at each NIC. OK. The window open up
(indicated through a new MaxCmdRn received on one connection). This
value now must be communicated to the other connections, so that
they can not be flow controlled also. Or the new value must be
received on each connection.

Also since you have posted a large enough number at each NIC,
you are really not having any benefit at all from the session-wide
value - what is the advantage?

2. Have the NICs grab them from a pool through an atomic bus
transaction. That has got to be tougher to implement than it
looks, and the bus performance issues due to the need to maintain
ordering etc?

> 
> 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
> >
> 
> 
>