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 <kw...@redhat.com> > Suggested-by: Stefan Hajnoczi <stefa...@redhat.com> > Signed-off-by: Brian Song <hibrians...@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
