Re: [PATCH v1 00/30] fuse/io-uring: add kernel-managed buffer rings and zero-copy

[Joanne Koong <joannelkoong@gmail.com>]

On Sat, Dec 13, 2025 at 5:14 PM Askar Safin <safinaskar@gmail.com> wrote:
>
> Joanne Koong <joannelkoong@gmail.com>:
> > This series adds buffer ring and zero-copy capabilities to fuse over io-uring.
>
> So this is superior modern io-uring-based zero-copy for fuse? I. e. modern alternative
> to splice fuse hacks here:
> https://elixir.bootlin.com/linux/v6.18-rc6/source/fs/fuse/dev.c#L979
> https://elixir.bootlin.com/linux/v6.18-rc6/source/fs/fuse/dev.c#L2291
> ?
>
> If so, then may I remove that fuse splice special-casing?
>
> I assume that splice for fuse is not that fast anyway despite that special-casing
> linked above. So code linked above introduce complexity to the kernel without
> giving any actual benefits. As opposed to truly fast modern uring interfaces.
>
> Fuse is the only user of "pipe_buf_confirm" outside of fs/pipe.c and fs/splice.c:
> https://elixir.bootlin.com/linux/v6.18-rc6/C/ident/pipe_buf_confirm
>
> It is the only user of "PIPE_BUF_FLAG_LRU" outside of fs/splice.c:
> https://elixir.bootlin.com/linux/v6.18-rc6/C/ident/PIPE_BUF_FLAG_LRU .
>
> It is the only user of "PIPE_BUF_FLAG_GIFT" outside of fs/splice.c:
> https://elixir.bootlin.com/linux/v6.18-rc6/C/ident/PIPE_BUF_FLAG_GIFT .
>
> It is one of the few users of "SPLICE_F_MOVE":
> https://elixir.bootlin.com/linux/v6.18-rc6/C/ident/SPLICE_F_MOVE .
>
> It is one of two callers of "pipe_buf_try_steal":
> https://elixir.bootlin.com/linux/v6.18-rc6/C/ident/pipe_buf_try_steal
> (the other is virtio-console).
>
> (Side note: Linus on pipe_buf_try_steal/SPLICE_F_GIFT: "Now, I would
> actually not disagree with removing that part. It's
> scary. But I think we don't really have any users (ok, fuse and some
> random console driver?)"
> - https://lore.kernel.org/all/CAHk-=whYWEUU69nY6k4j1_EQnQDNPy4TqAMvpf1UA111UDdmYg@mail.gmail.com/
> )
>
> So, removing special handling of splice in fuse will lead to simplifications
> in core pipe/splice code. And I think that we need to do this, because
> splice is not fast anyway, compared to uring.
>
> Also from Linus:
> > Side note: maybe I should clarify. I have grown to pretty much hate
> > splice() over the years, just because it's been a constant source of
> > sorrow in so many ways.
> ...
> > It's just that it was never as lovely and as useful as it promised to
> > be. So I'd actually be more than happy to just say "let's decommission
> > splice entirely, just keeping the interfaces alive for backwards
> > compatibility"
> ...
> > I'd be willing to *simplify* splice() by just
> > saying "it was all a mistake", and just turning it into wrappers
> > around read/write. But those patches would have to be radical
> > simplifications, not adding yet more crud on top of the pain that is
> > splice().
> >
> > Because it will hurt performance. And I'm ok with that as long as it
> > comes with huge simplifications. What I'm *not* ok with is "I mis-used
> > splice, now I want splice to act differently, so let's make it even
> > more complicated".
> - https://lore.kernel.org/all/CAHk-=wgG_2cmHgZwKjydi7=iimyHyN8aessnbM9XQ9ufbaUz9g@mail.gmail.com/
> - https://lore.kernel.org/all/CAHk-=wjixHw6n_R5TQWW1r0a+GgFAPGw21KMj6obkzr3qXXbYA@mail.gmail.com/
>
> For all these reasons, may I remove fuse splice special casing?

fuse uring is opt-in, not the default. Removing the splice
optimizations would regress performance for users who aren't using
uring, which is currently most of them.

Thanks,
Joanne

>
> --
> Askar Safin