I don't know there are such MQ HBA driver in tree,
HiSilicon SAS HBA can accept 4096 commands on any given hw queue but can
also only accept 4096 commands over all queues simultaneously. In fact, the
hw queue depth is configurable.
That's why I think that the definition is misleading.
That is why we call HiSilicon SAS is SQ device, still from
blk-mq/scsi-mq viewpoint, :-)
Sure, but this is the Scsi host interface, not the blk-mq interface.
So I think that the Scsi host interface is somewhat deficient as things
stand (for same reason I gave). It can be revisited.
I think I sound like a broken record now :)
at least that is the
current blk-mq/scsi-mq model: each hw queue has its own independent
tags, so there can't be the limit for MQ HBA, which should allow to
accept (.can_queue * nr_hw_queues) commands. And I did hear people
complains bad performance caused by the atomic .host_busy counter.
[...]
TBH, I'm not sure on the group of SCSI drivers which could benefit then.
As I see, only qla2xxx driver sets Scsi_host.nr_hw_queues and also uses
pci_alloc_irq_vectors_affinity().
Other non-SCSI drivers can benefit from that patchset too, such as NVMe.
Except for qla2xxx, there are also lpfc, virtio-scsi and smartpqi, and
there will be more since I heard that new version of one other popular
SCSI HBA will support real MQ.
OK, fine. So please check my latest reply on that thread when you have a
chance - I may have found an issue.
We have tried hosttags approach for the several drivers, but looks it is
too messy. Given there are only 3 or 4 such device, we still can improve
them via driver private approach in future if no generic way is doable.
ok, I'd rather not go on this path - you may say I'm digging my head in the
sand. Anyway, I'll continue to support the 'improve blk-mq for CPU hotplug'
effort.
I meant that way is the last straw, :-)
ok
Thanks,
John
Thanks,
Ming
.
