Re: [PATCH v9 00/17] fuse: fuse-over-io-uring.

[Bernd Schubert <bernd@bsbernd.com>]

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