Re: [PATCH v4 6/6] scsi: core: Improve IOPS in case of host-wide tags

[Damien Le Moal <dlemoal@kernel.org>]

On 12/20/25 02:35, Bart Van Assche wrote:
> On 12/16/25 7:24 PM, Damien Le Moal wrote:
>> On 12/17/25 07:30, Bart Van Assche wrote:
>>> The SCSI core uses the budget map to restrict the number of commands
>>> that are in flight per logical unit. That limit check can be left out if
>>> host->cmd_per_lun >= host->can_queue and if the host tag set is shared
>>> across all hardware queues or if there is only one hardware queue  Since
>>
>> Missing a period at the end of the sentence (before Since). But more
>> importantly, this does not explain why the above is true, and frankly, I do not
>> see it...
> Hi Damien,
> 
> The purpose of the SCSI device budget map is to prevent that the queue
> depth limit for that SCSI device is exceeded. If there is only a single
> hardware queue or there is a host-wide tag set and host->cmd_per_lun is
> identical to host->can_queue, it is not possible that the queue depth
> for a single SCSI device is exceeded and hence the SCSI device budget
> map is not needed.

Still very confusing because as far as I understand things, a host is not
necessarily a LUN/block device (you can have several devices/LUNs on the same
host). So in general host->can_queue != device max queue depth. Also, I am not
entirely sure if host->cmd_per_lun and max queue depth of the LUN are the same
thing, given that SCSI does not define a maximum device queue depth...

> Please help with reviewing the ATA patch in this series.

For AHCI, we are dealing with single queue devices, always. For this case, I do
not think that the scsi budget is needed since we will always have scsi tag ==
ATA tag, between 0 and 31. So if you can allocate a tag, you can always submit
the command.

But for libsas HBAs, I am not sure at all if what you did is solid/works,
because I still do not understand it. Please provide more detailed explanations
in your code (comments) and commit messages to better explain what you are doing
is safe.

> 
> Thanks,
> 
> Bart.


-- 
Damien Le Moal
Western Digital Research