On Fri, May 16, 2025 at 11:15 AM Bernd Schubert <bernd.schubert@xxxxxxxxxxx> wrote: > > 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. The issue is that there's no good way to transfer ownership of the buffer. The buffer belongs to the "struct fuse_buf" it's encapsulated inside. Libfuse passes to the server's write handler a pointer to the write payload inside the buffer. If the handler steals ownership of the buffer, the struct fuse_buf that buffer is in needs to set its ->mem to point to null. The only way I can think of to do this, which is hacky, is to add some "bool buffer_stolen : 1;" field to "struct fuse_file_info" since we pass "struct fuse_file_info *fi" to the write handler as an arg, and then in fuse_session_process_buf(), set "fuse_buf->mem = NULL" if fi->buffer_stolen was set by the handler. This changes the semantics of the fuse_session_process_buf() public API, which I don't believe is backwards compatible. The caller may supply its own buffer to fuse_session_{receive_process}_buf() and then do whatever it'd like with that buffer afterwards (eg reuse it for other data or dereference into it), but now that is not true anymore. > > With io-uring the buffer belongs to the request and not to the > thread anymore - no need to copy from libfuse to the server. I don't see how io-uring helps here. With io-uring, the ent payload is now the buffer, no? If a thread still needs that payload to process that data, it can't still utilize the pointer to that payload while allowing that ent to be used again for another request, no? Thanks, Joanne > > 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
