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. 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. Does this make sense? Thanks, Miklos
