On Thu, 15 May 2025 at 01:17, Joanne Koong <joannelkoong@xxxxxxxxx> wrote: > No. The server copies the buffer to another buffer (for later > processing) so that the server can immediately reply to the request > and not hold up work on that libfuse thread. Splice here helps because > it gets rid of 1 copy, eg instead of copying the data to the libfuse > buffer and then from libfuse buffer to this other buffer, we can now > just do a read() on the file descriptor returned from splice into the > other buffer. Yeah, splice is neat, but that pesky thing about the buffer liftimes makes it not all that desirable. So I'm wondering if the planned zero copy uring api is perhaps a better solution? In theory there's nothing preventing us from doing it with the plain /dev/fuse interface (i.e. read the FUSE_WRITE header and pass a virtual offset to the libfuse write callback, which can read the payload from the given offset), but perhaps the uring one is more elegant. Thanks, Miklos
