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). Thanks, Bernd
