On 26.03.25 06:38, Markus Armbruster wrote:
Hanna Czenczek <hre...@redhat.com> writes:
FUSE allows creating multiple request queues by "cloning" /dev/fuse FDs
(via open("/dev/fuse") + ioctl(FUSE_DEV_IOC_CLONE)).
We can use this to implement multi-threading.
Note that the interface presented here differs from the multi-queue
interface of virtio-blk: The latter maps virtqueues to iothreads, which
allows processing multiple virtqueues in a single iothread. The
equivalent (processing multiple FDs in a single iothread) would not make
sense for FUSE because those FDs are used in a round-robin fashion by
the FUSE kernel driver. Putting two of them into a single iothread will
just create a bottleneck.
Therefore, all we need is an array of iothreads, and we will create one
"queue" (FD) per thread.
[...]
Signed-off-by: Hanna Czenczek <hre...@redhat.com>
---
qapi/block-export.json | 8 +-
block/export/fuse.c | 214 +++++++++++++++++++++++++++++++++--------
2 files changed, 179 insertions(+), 43 deletions(-)
diff --git a/qapi/block-export.json b/qapi/block-export.json
index c783e01a53..0bdd5992eb 100644
--- a/qapi/block-export.json
+++ b/qapi/block-export.json
@@ -179,12 +179,18 @@
# mount the export with allow_other, and if that fails, try again
# without. (since 6.1; default: auto)
#
+# @iothreads: Enables multi-threading: Handle requests in each of the
+# given iothreads (instead of the block device's iothread, or the
+# export's "main" iothread).
When does "the block device's iothread" apply, and when "the export's
main iothread"?
Depends on where you set the iothread option.
Is this something the QMP user needs to know?
I think so, because e.g. if you set iothread on the device and the
export, you’ll get a conflict. But if you set it there and set this
option, you won’t. This option will just override the device/export option.
+# For this, the FUSE FD is duplicated so
+# there is one FD per iothread. (since 10.1)
Is the file descriptor duplication something the QMP user needs to know?
I found this technical detail interesting, i.e. how multiqueue is
implemented for FUSE. Compare virtio devices, for which we make it
clear that virtqueues are mapped to I/O threads (not just in
documentation, but actually in option naming). Is it something they
must not know?
Hanna
+#
# Since: 6.0
##
{ 'struct': 'BlockExportOptionsFuse',
'data': { 'mountpoint': 'str',
'*growable': 'bool',
- '*allow-other': 'FuseExportAllowOther' },
+ '*allow-other': 'FuseExportAllowOther',
+ '*iothreads': ['str'] },
'if': 'CONFIG_FUSE' }
##
[...]
