Re: [PATCH] [v2]aacraid: Reply queue mapping to CPUs based on IRQ affinity

[John Garry <john.g.garry@oracle.com>]

On 25/03/2025 00:16, Sagar.Biradar@microchip.com wrote:
>>>>
>>>> I've added the original authors of Bugzilla 217599[1] to the cc list to
>>>> get their attention and review.
>>>>
> Historically, the aacraid driver relied on the can_queue member of the scsi_host structure to determine the total number of cmds the FW could manage.
> With FW supporting 32 queues, each capable of handling 32 commands, the total command capacity was effectively 1024 (32*32).
> 
> This limit is a HW/FW limitation specific to the aacraid controller, which restricts each queue to a maximum of 32 cmds.
> 
> Starting from kernel version 6.4, the introduction of the map queue mechanism treated all queues as having the same capacity as can_queue, inadvertently exceeding the 1024 command limit.
> Consequently, relying solely on scsi_host->can_queue became unfeasible.
> To address this, the patch introduces logic to dynamically assign can_queue based on the number of available MSIX vectors (i.e., the number of queues) multiplied by 32.

I have not read all this thread, but ....

in case unknown, if you set shost->host_tagset when setting 
shost->nr_hw_queues > 1, this means that the total queue depth of the 
adapter (from block layer PoV) == each HW queue depth == shost->can_queue

If you don't set shost->host_tagset, then total queue depth (from block 
layer PoV) is shost->can_queue * shost->nr_hw_queues

> This approach ensures can_queue correctly reflects the hardware’s total command capacity, preventing issues caused by exceeding the 1024 limit.
> But this change causes a performance drop in some configurations.
> It's important to mention that the patch does not modify the queue depth itself but rather aligns can_queue with the hardware's fixed limit.
> 
> For comparison, competitor controllers typically support up to 256 commands per queue with an overall capacity of 8192 (256*32) cmds or more.
> While the aacraid controller's design has stricter hardware constraints, the patch ensures it functions optimally within these limits and hence the reduced performance.
> 
> Conclusion :
> A generic fix is not practical - given the performance drop.
> As John Meneghini suggested, instead of a modparam we could embed the same fix inside a kconfig option.
> 
> Should I submit a new version with the kconfig option?