Re: [PATCH RFC 1/1] block/export: FUSE-over-io_uring Support for QEMU FUSE Exports

[Kevin Wolf <kwolf@redhat.com>]

Am 16.07.2025 um 20:38 hat Brian Song geschrieben:
> This work provides an initial implementation of fuse-over-io_uring
> support for QEMU export. According to the fuse-over-io_uring protocol
> specification, the userspace side must create the same number of queues
> as the number of CPUs (nr_cpu), just like the kernel. Currently, each
> queue contains only a single SQE entry, which is used to validate the
> correctness of the fuse-over-io_uring functionality.
> 
> All FUSE read and write operations interact with the kernel via io
> vectors embedded in the SQE entry during submission and CQE fetching.
> The req_header and op_payload members of each entry are included as
> parts of the io vector: req_header carries the FUSE operation header,
> and op_payload carries the data payload, such as file attributes in a
> getattr reply, file content in a read reply, or file content being
> written to the FUSE client in a write operation.
> 
> At present, multi-threading support is still incomplete. In addition,
> handling connection termination and managing the "drained" state of a
> FUSE block export in QEMU remain as pending work.
> 
> Suggested-by: Kevin Wolf <kwolf@redhat.com>
> Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Brian Song <hibriansong@gmail.com>
> 
> ---
>  block/export/fuse.c                  | 423 +++++++++++++++++++++++++--
>  docs/tools/qemu-storage-daemon.rst   |  10 +-
>  qapi/block-export.json               |   6 +-
>  storage-daemon/qemu-storage-daemon.c |   1 +
>  util/fdmon-io_uring.c                |   5 +-
>  5 files changed, 420 insertions(+), 25 deletions(-)

You already got a lot of feedback on details. Let me add a more generic
point that should be addressed for a non-RFC submission: You should try
to limit each commit to a single logical change. You'll then send a
patch series instead of just a single patch where each patch works
incrementally towards the final state.

This makes it not only easier to review the changes because there is
less going on in each individual patch, but it will also be helpful if
we ever have to debug a problem and can bisect to a smaller change, or
even just because looking at the commit message in a few years is
likelier to explain why some specific code was written the way it is.

For example, your change to util/fdmon-io_uring.c could be the first
patch, enabling IORING_SETUP_SQE128 is a self-contained logical change.
You can mention in its commit message that it's in preparation for using
IORING_OP_URING_CMD.

Another patch could be refactoring fuse_co_process_request() so that it
works for both /dev/fuse based and io_uring based exports. (I agree with
Stefan that the code should be shared between both.)

And then you could see if adding io_uring support to the FUSE export
itself can be broken down into multiple self-contained changes or if
that part has to stay a single big patch. Maybe you can keep it similar
to how you're actually developing the code: First a patch with a minimal
implementation that processes one request per queue, then another one to
implement parallel I/O, then one for supporting multiple iothreads.


Another thing I wondered is if the large #ifdef'ed section with io_uring
helpers would actually make more sense as a separate source file
block/export/fuse-io_uring.c that can be linked conditionally if
io_uring is available. This would help to minimise the number of #ifdefs
in fuse.c.

Kevin