Re: qla2xxx: Conditionally disable automatic queue full tracking

[Michael Reed <mdr@sgi.com>]

Mike Christie wrote:
> On 09/29/2009 08:34 PM, Giridhar Malavali wrote:
>> 3) From your previous mail, I understand that you don't require a
>> combined limit per target. Say the total queue depth for all LUN's on a
>> particular target should not exceed some threshold.
>>
> 
> James Smart had done this patch
> http://marc.info/?l=linux-scsi&m=121070114018354&w=2
> where it sets the starget->can_queue based on info we get from vendors. 
> The patch did not get merged. JamesB does not want the 
> starget->can_queue to be static, and wants code like the queue full 
> tracking code which dynamically ramps the device queue depth up and down.

Agree.  Some amount of dynamic management of queue full seems desirable.
I believe any such dynamic management needs to acknowledge that it
exists in a multi-initiator environment, i.e., might get a QUEUE_FULL
with no other commands outstanding.

> 
> I am not sure if JamesB meant that he wants to ramp down the 
> starget->can_queue based on getting a QEUEU_FULL though. I thought he 
> just meant he wants it to be dynamic. 

What does "be dynamic" mean if not adjusted based upon a target's
response to scsi commands?

> If I am right, then I think we 
> could use JamesS's patch to set an initial starget->can_queue and add 
> another field for a max value. Then we could add some code that ramps 
> down/up based on something like command completion time or throughput or 
> some other value.

We don't necessarily need or want can_queue set by a value encoded into
a kernel table.  Some of our raid devices' can_queue values vary based
upon the firmware they are running.  A static table would, at best, be a
decent starting point.  At worst, it could dramatically over-commit the
target.  Our raid devices' max can_queue is either per raid controller
or per host port.

Whatever path we go down, I view having a user programmable upper bound
as a requirement.

> 
> If JamesS did mean that he wanted to ramp down the starget->can_queue 
> based on QUEUE_FULLs then JamesS and JamesB do not agree on that and we 
> are stuck.

I don't consider ramp up/down of starget->can_queue a requirement.
But I also don't consider its presence a problem.

Our requirements are pretty simple: the ability to limit the number
of commands queued to a target or lun in a multi-initiator environment
such that no individual initiator can fully consume the resources
of the target/lun.  I.e., we want a user programmable upper bound
on all queue_depth and can_queue adjustments.  (Yes, I've stated this
a few times.  :)


Mike