Re: [PATCH 11/12] virtio-scsi: add iothread-vq-mapping parameter

[Kevin Wolf <kwolf@redhat.com>]

Am 13.02.2025 um 19:00 hat Stefan Hajnoczi geschrieben:
> Allow virtio-scsi virtqueues to be assigned to different IOThreads. This
> makes it possible to take advantage of host multi-queue block layer
> scalability by assigning virtqueues that have affinity with vCPUs to
> different IOThreads that have affinity with host CPUs. The same feature
> was introduced for virtio-blk in the past:
> https://developers.redhat.com/articles/2024/09/05/scaling-virtio-blk-disk-io-iothread-virtqueue-mapping
> 
> Here are fio randread 4k iodepth=64 results from a 4 vCPU guest with an
> Intel P4800X SSD:
> iothreads IOPS
> ------------------------------
> 1         189576
> 2         312698
> 4         346744
> 
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

As Peter already noted, the interface is a bit confusing in that it
considers the control and event queue just normal queues like any other
and you need to specify a mapping for them, too (even though you
probably don't care about them).

I wonder if it wouldn't be better to use the iothread-vq-mapping
property only for command queues and to have separate properties for the
event and control queue. I think this would be less surprising to users.

It would also allow you to use the round robin allocation for command
queues while using a different setting for the special queues - in
particular, the event queue is currently no_poll, which disables polling
for the whole AioContext, so you probably want to have it just anywhere
else, but not in the iothreads you use for command queues. This should
probably also be the default.

Kevin