RE: ISCSI: flow control

[Robert Reynolds <robertr@Crossroads.com>]

 Would this credit be on an LU<->Initiator pair?  If not, then
 the LU could advertise a credit of 10 to Initiator A.  Initiator
 A would then send 10 commands without any knowledge that some
 other initiator may have also sent commands to that same LU. The 
 end result is that the targets command queue is still overrun.

 If the credit is on an LU<->Initiator pair then how does the
 target divide up it's resources in a multi-initiator environment
 where a new initiator could come on-line at any time?

> -----Original Message-----
> From: Michael Krause [mailto:krause@cup.hp.com]
> Sent: Sunday, September 24, 2000 10:51 PM
> To: Pierre Labat; Robert Snively
> Cc: ips@ece.cmu.edu
> Subject: Re: ISCSI: flow control
> 
> 
> At 10:53 AM 9/24/00 -0700, Pierre Labat wrote:
> 
> 
> >T10 could add an advertising of a command credit. For example
> >when the status is returned the target gives a command credit.
> 
> In essence, this is what InfiniBand does and others have been 
> advocating.  When the ACK (SCSI response) is returned it 
> encodes a credit 
> to inform the sender of how many receives buffers (available 
> command queue 
> slots) have been posted. This allows the sender to know 
> whether it can 
> continue to issue send operations.  The cost is trivial in 
> hardware and 
> greatly simplifies the software / control logic since it can 
> post as many 
> commands as it wants on the requester and these will be 
> processed at the 
> rate the receiver can actually consume them.  When combined 
> with the RNR 
> NAK operation (still applicable since there may be other reasons for 
> returning this), one can achieve a fairly robust and simple 
> implementation 
> that works across a wide range of products.
> 
> Mike
>