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

[David Wei <dw@davidwei.uk>]

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