On 5/16/25 09:58, Miklos Szeredi wrote:
On Thu, 15 May 2025 at 21:16, Joanne Koong <joannelkoong@xxxxxxxxx> wrote:
As I understand it, the zero copy uring api (I think the one you're
talking about is the one discussed here [1]?) requires client-side
changes in order to utilize it.
[1] https://lore.kernel.org/linux-fsdevel/dc3a5c7d-b254-48ea-9749-2c464bfd3931@xxxxxxxxxxx/
No, that's not what I was thinking. That sort of thing is out of
scope for fuse, I think.
Yeah, I don't think that is what Keith had done for ublk either and what is
planned for fuse. Added in Keith.
Hmm, so you actually need "single copy" direct write.
- there's the buffer that write(2) gets from application
- it's copied into server's own buffer, at which point the write(2) can return
- at some point this buffer is sent to the network and freed/reused
Currently this is not possible:
- there's the buffer that write(2) gets from application
- it's copied into libfuse's buffer, which is passed to the write callback
- the server's write callback copies this to its own buffer, ...
What's preventing libfuse to allow the server to keep the buffer? It
seems just a logistic problem, not some fundamental API issue. Adding
a fuse_buf_clone() that just transfers ownership of the underlying
buffer is all that's needed on the API side. As for the
implementation: libfuse would then need to handle the case of a buffer
that has been transferred.
With io-uring the buffer belongs to the request and not to the
thread anymore - no need to copy from libfuse to the server.
AFAIK, mergerfs also uses a modified libfuse that also allows to keep
the server the buffer without io-uring. I just don't see much of
a point to work on these things when we have io-uring now.
Thanks,
Bernd
