Re: command queueing cmd_per_lun, queue_depth and tags

[Brian King <brking@us.ibm.com>]

Patrick Mansfield wrote:
> On Fri, Apr 07, 2006 at 05:29:28PM -0500, Brian King wrote:
>> Patrick Mansfield wrote:
>>> Currently cmd_per_lun is the default queue depth for both tagged and
>>> untagged queueing. That is, if the LLDD does not modify queue_depth in its
>>> slave_configure, queue_depth will be set to cmd_per_lun, no matter what
>>> the command queueing/tag support. 
>>>
>>> If we don't allow queueing in the LLDD, and cmd_per_lun is supposed to be
>>> the default depth for untagged support, shouldn't it always be 1, and
>>> hence go away? 
>> This seems to assume there are no SCSI devices which do command queuing, but do
>> not support queue tags. This is not the case.
> 
> I should not have used "untagged", that is misleading and a problem with
> current scsi core, where we reference tcq, tags, and don't seem to mention
> task attributes.
> 
> But LLDD can override anything in slave_configure.

I guess my biggest problem with this part of the patch is that it prevents an
LLDD that wants this behavior from being able to use scsi_adjust_queue_depth
to set the queue depth, whether it be in slave_configure, change_queue_depth, etc.

> Also, it looks like we could safely use cmd_per_lun as the default
> queue_depth, rather than setting it to 1 as done in my previous
> post/patch.

Ok. If we do that and also allow scsi_adjust_queue_depth
to adjust the queue depth when tagged == 0, as is allowed today,
then I think most of my objections to the patch should disappear,
although it may require me to make a couple ipr changes.

>>> Similarily, why do some LLDD's use a cmd_per_lun of 3, or (like
>>> ncr53c8xx_slave_configure) set queue_depth for !tagged_supported to
>>> anything other than 1?
>> In the case of ipr, there are two scenarios. The first is for JBOD disks.
>> I use a default queue depth of 6 in ipr. When running untagged, with a queue depth
>> of > 1, the ipr adapter firmware then maintains a queue, guaranteeing only
>> one command will be outstanding to the device at once. This lower level
>> queue allows for a faster turnaround of commands and improved performance.
>> The second case is that of RAID arrays. These show up as logical scsi disks.
>> They support command queueing, but not tagged command queueing.
> 
> So you just want the task attibutes, and don't care about tag management
> (i.e. you don't ever use cmd->request->tags)? That is similar to FCP.

Correct. The ipr adapter firmware generates its own queue tags before sending
tagged commands to the device. 

>>> I know (at least) FCP can always do simple queueing, but I don't think
>>> scsi core should allow multiple commands to be sent if the device does not
>>> have CMDQUE (or BQUE).
>> This will break both of the working scenarios I described above for ipr
>> and performance will suffer significantly. The inquiry data for ipr RAID
>> arrays does not set either CMDQUE or BQUE.
> 
> Sounds like they are sort of SCSI-2 compliant, that is allowed there but
> mentioned as obsolete in current SCSI-3 (spc3r23.pdf).
> 
> The LLDD can override the queue_depth for these cases.

Agreed, but my first comment applies here as well.

>>> Also we don't even check the BQUE in the INQUIRY result (byte 6, bit 7).
>>> Should this be changed? That is set tagged_supported if BQUE is set, like
>>> we do for CMDQUE (byte 7 bit 1). And also set simple_tags if
>>> tagged_supported is set.
>> I don't like the idea of always enabling TCQ in scsi core simply if
>> the device supports it. What if the HBA does not support it? To make
>> matters more interesting, what if the HBA does not support TCQ, but does
>> support untagged command queueing, similar to ipr as described above?
> 
> They can override it in slave_configure.

Sure. I could add a scsi_deactivate_tcq in slave_configure.


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center