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

[Joanne Koong]

On Thu, Apr 23, 2026 at 4:11 AM Li Wang <liwang@xxxxxxxxxx> wrote:
>
> Deliver FUSE_FORGET through fuse_uring_queue_fuse_req() when the io_uring
> is ready and userspace has opted in by setting
> FUSE_IO_URING_REGISTER_FORGET_COMMIT in fuse_uring_cmd_req.flags on
> FUSE_IO_URING_CMD_REGISTER. Until any REGISTER
> carries that bit, FORGET continues to use the legacy
> fuse_dev_queue_forget() path even while io_uring is active, so unmodified
> userspace (e.g. libfuse that does not issue a completion SQE for FORGET)
> does not wedge ring entries.
>
> Benefits:
> - FORGET can share the same commit/fetch loop as other opcodes.
> - Reduces split transport for high-volume forgets when the ring is primary.
> - Reuses existing per-queue io-uring machinery and noreply/force
>   request setup.
>
> Signed-off-by: Li Wang <liwang@xxxxxxxxxx>

Hi Li,

Thanks for sending this. To be completely honest, I'm not convinced
delivering forget over io-uring is worth the added complexity/cost. In
the /dev/fuse path we rely on forget batching/amoritizing and explicit
scheduling/fairness logic so forget processing makes progress and
doesn't get drowned out by regular requests; I think we'd likely need
something comparable for the io-uring path as well. Additionally,
routing it through io-uring makes forget behave more like a "real"
request on the ring (it needs per-request state to live until
userspace completes and the entry can be recyycled) which introduces
extra allocation/lifetime management on this path and it requires a
uapi change and corresponding libfuse changes.

Forgets would consume ring entries but they're tiny one-way
notifications and imo I don't think they benefit much from io-uring's
main advantages (eg data-path/zero-copy). I worry theyy could contend
with read-write heavy traffic where ring capacity is more valuable.

Given that, my preference would be to keep forget/interrupts on the
legacy /dev/fuse path even when io-uring is enabled. Sorry for not
bringing this up earlier in v2. Bernd, I’d also be curious to hear
your perspective on this.

Thanks,
Joanne