Re: [PATCH v4 0/4] virtio-blk: add iothread-vq-mapping parameter

[Kevin Wolf]

Am 20.12.2023 um 14:47 hat Stefan Hajnoczi geschrieben:
> v4:
> - Use DummyVirtioForceArrays naming in QAPI schema [Markus]
> v3:
> - Rebased onto Kevin's block branch
> - Add StringOutputVisitor "<omitted>" patch to fix "info qtree" crash
> - Fix QAPI schema formatting [Markus]
> - Eliminate unnecessary local variable in get_iothread_vq_mapping_list() 
> [Markus]
> 
> virtio-blk and virtio-scsi devices need a way to specify the mapping between
> IOThreads and virtqueues. At the moment all virtqueues are assigned to a 
> single
> IOThread or the main loop. This single thread can be a CPU bottleneck, so it 
> is
> necessary to allow finer-grained assignment to spread the load. With this
> series applied, "pidstat -t 1" shows that guests with -smp 2 or higher are 
> able
> to exploit multiple IOThreads.
> 
> This series introduces command-line syntax for the new iothread-vq-mapping
> property is as follows:
> 
>   --device 
> '{"driver":"virtio-blk-pci","iothread-vq-mapping":[{"iothread":"iothread0","vqs":[0,1,2]},...]},...'
> 
> IOThreads are specified by name and virtqueues are specified by 0-based
> index.
> 
> It will be common to simply assign virtqueues round-robin across a set
> of IOThreads. A convenient syntax that does not require specifying
> individual virtqueue indices is available:
> 
>   --device 
> '{"driver":"virtio-blk-pci","iothread-vq-mapping":[{"iothread":"iothread0"},{"iothread":"iothread1"},...]},...'
> 
> There is no way to reassign virtqueues at runtime and I expect that to be a
> very rare requirement.
> 
> Note that JSON --device syntax is required for the iothread-vq-mapping
> parameter because it's non-scalar.
> 
> Based-on: 81e69329d6a4018f4b37d15b6fc845fbe585a93b 
> (https://repo.or.cz/qemu/kevin.git block)

Thanks, applied to the block branch. We agreed off-list that the
remaining problems can be fixed in follow-up patches.

Kevin