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

[Askar Safin <safinaskar@gmail.com>]

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?

-- 
Askar Safin