Re: [PATCH v6 0/6] fuse: add io-uring buffer pools and zero-copy

On Thu, 16 Jul 2026 at 19:59, Joanne Koong <[email protected]> wrote:
>
> This series adds fuse io-uring buffer pools and zero-copy.
>
> Prior to this series, ents and buffers are tightly coupled where each entry
> has its own dedicated payload buffer, requiring N buffers for N entries where
> each buffer must be large enough to accomodate the maximum payload size. This
> is suboptimal as most request types require vastly less bytes than the maximum
> payload size and some requests do not require payload buffers at all.
>
> This series allows servers to pass in a buffer pool (a contiguous chunk of
> memory) that the kernel will use as it wishes for servicing ents/requests.
> This decoupling reduces the memory usage requirements needed to use
> fuse-io-uring and lets the kernel do any optimizations for assigning payload
> memory to requests.
>
> This series additionally adds zero copy to fuse io-uring. The server can
> directly access client pages or page cache folios without copying data through
> an intermediary buffer. This requires CAP_SYS_ADMIN privileges and using
> buffer pools. The zero copy patch has a dependency on io-uring registered
> bvec changes in [1].
>
> This series is on top of commit 7d87a5a284bb and on top of the io-uring bvec
> changes and the changes from the series in [2] applied.
>
> The throughput improvements from registered buffers and zero-copy depends on
> how much of the server's per-request latency is spent on data copying vs
> backing I/O. When backing I/O dominates, the saved memcpy is a negligible
> fraction of overall latency. Please also note that for the server to
> read/write into the zero-copied pages, the read/write must go through io-uring
> as an IORING_OP_READ_FIXED / IORING_OP_WRITE_FIXED operation.
>
> The throughput improvement from zero-copy depends on how much of the
> per-request latency is spent on data copying vs backing I/O. The gain
> comes from eliminating the payload-buffer memcpy,  but accessing the
> zero-copied pages requires the server to issue the read/write as an
> IORING_OP_READ/WRITE_FIXED operation. The benefit is largest when the
> mempcy is a meaningful fraction of per-request latency while backing i/o
> is still noticable enough that the extra io-uring op's overhead doesn't
> dominate.
>
> Benchmarked with passthrough_hp (--nopassthrough, q_depth=8) on a
> 2-socket Intel Xeon Gold 6138 (40 cores / 80 threads), using fio (sync
> engine, bs=1M, O_DIRECT, numjobs=2, 30s run + 10s ramp, 3 runs) where
> direct-I/O throughput is against a RAM-backed (tmpfs) source (backing
> I/O is not the bottleneck):
>
>                 baseline   registered-buf   zero-copy   (zc vs base)
> direct read     ~5.1 GB/s  ~5.4 GB/s        ~8.9 GB/s   (+75%)
> direct write    ~3.4 GB/s  ~4.8 GB/s        ~5.1 GB/s   (+50%)

The interface changes make sense and the benchmark results look impressive.

I think if the synchronization between INIT is sorted out then this is
good to go.  Sashiko can't apply the series, I guess because of the
non-standard base.   Not sure if we can help that.

Also because Bernd and you are co-maintainers of fuse-uring, I'd hope
for an ack from Bernd (when he returns from vacation).

Thanks,
Miklos