On Tue, Apr 01, 2025 at 02:05:40PM +0200, Kevin Wolf wrote: > > Maybe we could make setting @iothreads here and the generic > > BlockExportOptions.iothread at the same time an error. That would save us > > the explanation here. > > This raises the question if the better interface wouldn't be to change > the BlockExportOptions.iothread from 'str' to an alternate between 'str' > and ['str'], allowing the user to specify multiple iothreads in the > already existing related option without creating conflicting options. > > In the long run, I would be surprised if FUSE remained the only export > supporting multiple iothreads. At least the virtio based ones > (vhost-user-blk and VDUSE) even have precedence in the virtio-blk device > itself, so while I don't know how much interest there is in actually > implementing it, in theory we know it makes sense.
And I really want my work on NBD Multi-conn support to merge well with multiple iothreads. That is yet another case where even if the I/O is single-threaded, having parallel connections to the NBD server via round-robin of requests can improve throughput. But if you can afford to assign four iothreads to manage four TCP connections to a single NBD server, you'll get even better response. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
