Re: [PATCH v3 24/25] fuse: add zero-copy over io-uring

[Joanne Koong <joannelkoong@gmail.com>]

On Thu, Jan 8, 2026 at 1:15 PM Caleb Sander Mateos
<csander@purestorage.com> wrote:
>
> On Mon, Dec 22, 2025 at 4:37 PM Joanne Koong <joannelkoong@gmail.com> wrote:
> >
> > Implement zero-copy data transfer for fuse over io-uring, eliminating
> > memory copies between kernel and userspace for read/write operations.
> >
> > This is only allowed on privileged servers and requires the server to
> > preregister the following:
> > a) a sparse buffer corresponding to the queue depth
> > b) a fixed buffer at index queue_depth (the tail of the buffers)
> > c) a kernel-managed buffer ring
> >
> > The sparse buffer is where the client's pages reside. The fixed buffer
> > at the tail is where the headers (struct fuse_uring_req_header) are
> > placed. The kernel-managed buffer ring is where any non-zero-copied args
> > reside (eg out headers).
> >
> > Benchmarks with bs=1M showed approximately the following differences in
> > throughput:
> > direct randreads: ~20% increase (~2100 MB/s -> ~2600 MB/s)
> > buffered randreads: ~25% increase (~1900 MB/s -> 2400 MB/s)
> > direct randwrites: no difference (~750 MB/s)
> > buffered randwrites: ~10% increase (950 MB/s -> 1050 MB/s)
> >
> > The benchmark was run using fio on the passthrough_hp server:
> > fio --name=test_run --ioengine=sync --rw=rand{read,write} --bs=1M
> > --size=1G --numjobs=2 --ramp_time=30 --group_reporting=1
> >
> > Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
> > ---
> >  fs/fuse/dev.c             |   7 +-
> >  fs/fuse/dev_uring.c       | 176 +++++++++++++++++++++++++++++++-------
> >  fs/fuse/dev_uring_i.h     |  11 +++
> >  fs/fuse/fuse_dev_i.h      |   1 +
> >  include/uapi/linux/fuse.h |   6 +-
> >  5 files changed, 164 insertions(+), 37 deletions(-)
> >
> > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> > index ceb5d6a553c0..0f7f2d8b3951 100644
> > --- a/fs/fuse/dev.c
> > +++ b/fs/fuse/dev.c
> > @@ -1229,8 +1229,11 @@ int fuse_copy_args(struct fuse_copy_state *cs, unsigned numargs,
> >
> >         for (i = 0; !err && i < numargs; i++)  {
> >                 struct fuse_arg *arg = &args[i];
> > -               if (i == numargs - 1 && argpages)
> > -                       err = fuse_copy_folios(cs, arg->size, zeroing);
> > +               if (i == numargs - 1 && argpages) {
> > +                       if (cs->skip_folio_copy)
> > +                               return 0;
> > +                       return fuse_copy_folios(cs, arg->size, zeroing);
> > +               }
> >                 else
> >                         err = fuse_copy_one(cs, arg->value, arg->size);
> >         }
> > diff --git a/fs/fuse/dev_uring.c b/fs/fuse/dev_uring.c
> > index e9905f09c3ad..d13fce2750e1 100644
> > --- a/fs/fuse/dev_uring.c
> > +++ b/fs/fuse/dev_uring.c
> > @@ -89,8 +89,14 @@ static void fuse_uring_flush_bg(struct fuse_ring_queue *queue)
> >         }
> >  }
> >
> > +static bool can_zero_copy_req(struct fuse_ring_ent *ent, struct fuse_req *req)
> > +{
> > +       return ent->queue->use_zero_copy &&
> > +               (req->args->in_pages || req->args->out_pages);
> > +}
> > +
> >  static void fuse_uring_req_end(struct fuse_ring_ent *ent, struct fuse_req *req,
> > -                              int error)
> > +                              int error, unsigned issue_flags)
> >  {
> >         struct fuse_ring_queue *queue = ent->queue;
> >         struct fuse_ring *ring = queue->ring;
> > @@ -109,6 +115,12 @@ static void fuse_uring_req_end(struct fuse_ring_ent *ent, struct fuse_req *req,
> >
> >         spin_unlock(&queue->lock);
> >
> > +       if (ent->zero_copied) {
> > +               WARN_ON_ONCE(io_buffer_unregister(ent->cmd, ent->fixed_buf_id,
>
> io_buffer_unregister() can fail if the registered buffer index has
> been unregistered or updated with a userspace buffer since the call to
> io_buffer_register_bvec(). So this WARN_ON_ONCE() can be triggered
> from userspace. I think it would be preferable to ignore the error or
> report it to the fuse server.

Sounds good, this was a remnant from when registered buffers had been
pinned. I'll remove this WARN_ON in v4.

Thanks,
Joanne
>
> Best,
> Caleb
>