Re: [PATCH v3] fuse: optional FORGET delivery over io_uring

[Li Wang]

Hi Joanne,

On 27/04/2026 19:31, Joanne Koong wrote:
> On Mon, Apr 27, 2026 at 10:56 AM Li Wang <liwang@xxxxxxxxxx> wrote:
>>
>> Hi Bernd and Joanne,
>>
>> On 26/04/2026 23:48, Bernd Schubert wrote:
>>>
>> Furthermore, in the current implementation, forget and I/O requests are
>> dispatched through different paths and handled by different sets of threads.
>> This means we cannot guarantee their original priority order upon reception,
> 
> I don't think ordering matters. forgets are inherently asynchronous
> and there's no correctness dependency on a forget arriving before or
> after a read/write request. In the /dev/fuse path ordering isn't
> preserved either (eg the order they're queued by the kernel is not the
> order they're delivered to userspace).
> 

Yeah, I agree, and I apologize for the confusion. By 'original', 
I meant the logic used before the io_uring path was introduced — where the 
system prioritized reading FORGET requests into the userspace buffer 
while still maintaining fairness. I wasn't referring to the order in which 
the system receives those requests.

That said, I’m curious: since FORGET is asynchronous and doesn't require 
a reply, it doesn't seem particularly urgent. Why prioritize it? To prevent 
a large memory footprint for metadata-heavy workloads? Could we be more 
aggressive with delays and only send them in batches once a certain 
threshold is met? Also, if a FORGET request is lost for whatever reason, 
what are the consequences? Is it just a matter of causing a memory leak?

Thanks,
Li