Re: [PATCH v3 0/3] scsi: add attribute to set lun queue depth on all luns on shost

[James Smart <jsmart2021@gmail.com>]

On 2/4/2020 6:56 PM, Martin K. Petersen wrote:
> 
> James,
> 
>> There has been a desire to set the lun queue depth on all luns on an
>> shost. Today that is done by an external script looping through
>> discovered sdevs and set an sdev attribute. The desire is to have a
>> single shost attribute that performs this work removing the
>> requirement for scripting.
> 
> I'd like you to elaborate a bit on this.
> 
>   - Why is scripting or adding a udev rule inadequate?

Simply put, admins don't want to create them, mod the system for them, 
nor concern themselves with finding/changing each of the lun devices 
that connect to a particular port. They have been comfortable changing 
the driver's initial lun queue depth via module parameter. Given that 
was at driver load, it changed everything at time of initial discovery 
so it was fine. But, if the system won't boot for days/weeks, they want 
to do something as simple as the module parameter and with only "1 echo 
command". Thus we wanted to make the parameter be rw rather than ro. 
However, the only interface available to the lldd was 
scsi_change_queue_depth(), which changes the depth but does not change 
the devices max value (which it does do if written via the per-device 
attribute). So although the now writeable attribute allows the driver 
value to change, it would only be applied to storage devices discovered 
after the change. Existing devices would not have their max changed 
unless the per-device attribute were changed.  This new interface gave 
the lldd a new routine, which would find all the devices and apply the 
new max/value to the devices - as if the per-device attributes had been 
called.

> 
>   - Why is there a requirement to statically clamp the queue depth
>     instead of letting the device manage it?

You are misreading it, and perhaps my description led things astray. It 
doesn't "clamp" it at a fixed/unchangable depth. It sets the max to a 
new value and changes the current queue depth to that new value. These 
are the same actions that the per-device attribute does if written to. 
The management of queue depth depth beyond that point is the same as it 
was - meaning queue fulls ramp it down, there is ramp up, and so on. So 
it is the device managing it, just with perhaps a small blip if it 
actually raised vs it's current level, or a pause if its current level 
was higher and it drains down to the new levels.

-- james