On Thu, May 15, 2025 at 1:38 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > 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. 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/ Thanks, Joanne > > Thanks, > Miklos
