On 2025-06-23 14:36, Bernd Schubert wrote:
On 6/20/25 03:39, xiaobing.li wrote:
On Wed, Jun 18, 2025 at 09:30:51PM -0600, Keith Busch wrote:
On Wed, Jun 18, 2025 at 03:13:41PM +0200, Bernd Schubert wrote:
On 6/18/25 12:54, xiaobing.li wrote:
Hi Bernd,
Do you have any plans to add zero copy solution? We are interested in
FUSE's zero copy solution and conducting research in code.
If you have no plans in this regard for the time being, we intend to
submit our solution.
Hi Xiobing,
Keith (add to CC) did some work for that in ublk and also planned to
work on that for fuse (or a colleague). Maybe Keith could
give an update.
I was initially asked to implement a similar solution that ublk uses for
zero-copy, but the requirements changed such that it won't work. The
ublk server can't directly access the zero-copy buffers. It can only
indirectly refer to it with an io_ring registered buffer index, which is
fine my ublk use case, but the fuse server that I was trying to
enable does in fact need to directly access that data.
My colleauge had been working a solution, but it required shared memory
between the application and the fuse server, and therefore cooperation
between them, which is rather limiting. It's still on his to-do list,
but I don't think it's a high priority at the moment. If you have
something in the works, please feel free to share it when you're ready,
and I would be interested to review.
Hi Bernd and Keith,
In fact, our current idea is to implement a similar solution that ublk uses
for zero-copy. If this can really further improve the performance of FUSE,
then I think it is worth trying.
By the way, if it is convenient, could you tell me what was the original
motivation for adding io_uring, or why you want to improve the performance
of FUSE and what you want to apply it to?
At DDN we have mainly a network file system using fuse - the faster it
runs the better. But we need access to the data for erasure,
compression, etc. Zero-copy would be great, but I think it is
unrealistic that application would change their API just for fuse to get
the coorporating model that David suggests (at least in our case).
Similar for us at Meta.
I have been toying with an idea of a solution that does not need (major)
client change and does not depend on FUSE io_uring. I think if it works
then it will be more broadly applicable and useful.
I'll have something to share soon.
David
Thanks,
Bernd
