On 6/23/25 23:55, David Wei wrote: > 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. > Out of interest, what is that concept? Thanks, Bernd
