On 11/27/24 13:40, Bernd Schubert wrote:
[I removed RFC status as the design should be in place now
and as xfstests pass. I still reviewing patches myself, though
and also repeatings tests with different queue sizes.]
I left a few comments, but it looks sane. At least on the io_uring
side nothing weird caught my eye. Cancellations might be a bit
worrisome as usual, so would be nice to give it a good run with
sanitizers.
This adds support for uring communication between kernel and
userspace daemon using opcode the IORING_OP_URING_CMD. The basic
approach was taken from ublk.
Motivation for these patches is all to increase fuse performance,
by:
- Reducing kernel/userspace context switches
- Part of that is given by the ring ring - handling multiple
requests on either side of kernel/userspace without the need
to switch per request
- Part of that is FUSE_URING_REQ_COMMIT_AND_FETCH, i.e. submitting
the result of a request and fetching the next fuse request
in one step. In contrary to legacy read/write to /dev/fuse
- Core and numa affinity - one ring per core, which allows to
avoid cpu core context switches
A more detailed motivation description can be found in the
introction of previous patch series
https://lore.kernel.org/r/20241016-fuse-uring-for-6-10-rfc4-v4-0-9739c753666e@xxxxxxx
That description also includes benchmark results with RFCv1.
Performance with the current series needs to be tested, but will
be lower, as several optimization patches are missing, like
wake-up on the same core. These optimizations will be submitted
after merging the main changes.
--
Pavel Begunkov
