Re: PATCH: scsi device queue depth adjustability patch

[James Bottomley <James.Bottomley@steeleye.com>]

dledford@redhat.com said:
> > How do HBA's that don't support this now work?

> The mid layer calls into the HBA driver's select_queue_depths()
> function  and the driver sets the queue depth on each device from
> there. 

> >  You've taken any dependency on 
> > scsi_host.cmd_per_lun out of the code (thus rendering it useless) so every HBA 
> > driver now is forced to use an initial queue depth adjustment just to start 
> > tagged command queueing.

> This is true both before and after my patch.  If the HBA doesn't implement 
> the select_queue_depths function then it will never get tagged queueing.  

But that's not quite how it works today.

If a HBA driver doesn't implement select_queue_depths, it can still set the 
template cmd_per_lun and have the mid layer build it this many commands per 
device (that's the line in scsi_build_commands which sets queue_depth to 
cmd_per_lun if its still unset), and hence you have an effective default 
tagged queue depth of cmd_per_lun.

The patch will break this, and thus disable TCQ for all drivers that rely on 
it.

> Besides, cmd_per_lun is *not* for tagged queueing, it's the queue depth 
> the scsi mid layer is suppossed to keep for *non* tagged devices.

The comment in the code above this parameter says: "...Set this to the maximum 
number of command blocks to be provided for each device.  Set this to 1 for 
one command block per lun, 2 for two, etc."  It's not unreasonable to assume 
this means the maximum number of outstanding tags.

Even if we assume it means what you say, how does the non TCQ HBA that sets 
this to 2 so every device always has one outstanding command and one ready to 
roll work? Now it only gets one command block because we never consult 
cmd_per_lun.

James