Subject: RE: [Ips] DA+iSER Flow Control, Limiting number of oustanding cmds at target

From: "Alex Nezhinsky" <[email-masked]>
Date: Wed, 22 Sep 2004 19:48:27 +0200

> The target uses MaxCmdSN to indicate the maximum CmdSN the 
> initiator can send.  In other words, it allows the target to 
> determine the number of pre-posted buffers required to 
> receive those commands.  However, it is up to the initiator 
> to determine how many commands, up to MaxCmdSN - ExpCmdSN 
> + 1, that it wants to send, which in turn determines the number of
> pre-posted buffers needed at the initiator to receive the 
> responses to those commands that are sent (SCSI Response, Reject,
etc.). 

Sure, this is exactly what I meant by: 
            >> the instant values of this parameter change from time to 
            >> time, and initiator learns them dynamically

>  This has worked well for iSCSI and I don't 
> see any reason why a new key needs to be added for iSER.

The only reason may be that the initiator does not know the upper bound
when it executes Allocate_Connection_Resources. 
Thus it should guess how much buffers should be allocated for the worst
case. 
This number may be too small, and then, in order to take advantage of
the greater concurrency level 
offered by the target additional buffers should be allocated. This
allocation attempt can fail.
In iSCSI the buffers are allocated by the iSCSI layer itself. It has the
liberty of trying to allocate additional buffers 
and if failed, to decide to pospone the command. 
In iSER Allocate_Connection_Resources is supposed to allocate *all*
resources which can be ever needed by the connection, so this poses a
problem.
If the initiator has a configuration parameter which places its own
upper bound on the number of 
simultaneously outstanding tasks, and if it happens to be smaller than
the one actually employed 
by the target, then it's ok. If this parameter value (or the initiator's
wild guess) is greater,  
then the initiator will try to allocate more buffers than it is actually
required. 
This may lead to an unjustified Allocate_Connection_Resources failure.  

Alexander Nezhinsky

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 22 Sep 2004 14:00:09 -0700

Alex,

 > when it executes Allocate_Connection_Resources.

It appears that your concern is wrt sizing of per-task buffer resources 
on the invocation of Allocate_Connection_Resources.

Note that section 9.4 in DA says the following:

"Note
that the Datamover layer however does not allocate any
Datamover-specific task-level resources upon invocation of
this Primitive."

The task buffers are thus not related to Allocate_Connection_Resources. 
  The buffer management is specific to implementations.  DA only 
specifies the architectural primitives that are minimally required to 
allow the definition of a Datamover protocol, but not everything for an 
implementation.

Thanks.
-- 
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

---

From: Julian Satran <[email-masked]>
Date: Fri, 24 Sep 2004 18:48:35 +0100

Alex,

MaxCmdSN is negotiated. The target and the initiator can set themselves 
bounds per connection and/or total and "downgrade" any attempt to exceed 
the bounds.
There is no need to negotiate a bound. Am I missing something?

Julo

"Alex Nezhinsky" <[email-masked]> 
Sent by: [email-masked]
22/09/04 19:48

To
"Mike Ko" <[email-masked]>
cc
[email-masked]
Subject
RE: [Ips] DA+iSER Flow Control, Limiting number of oustanding cmds at 
target

etc.). 

Alexander Nezhinsky