transport/io_uring currently narrows io_uring user_data from its native 64-bit field to short.
This makes one-shot operation tracking unnecessarily restrictive. A dedicated DefaultIoUringIoRegistration per op is too expensive, while limiting completion correlation to short forces awkward sharding across multiple registrations per EventLoop as the available space is exhausted.(it cannot even reliably carry values such as an fd.)
We should support long user data in the io_uring path to remove this artificial limit and make shared registration reuse scale better.
One possible direction is to assign each submitted op a sequence number and keep the op-specific state, such as the original user data and associated IoRegistration, in a separate tracking structure.
I already have an initial implementation that supports this use case. If this direction aligns with Netty's plans for transport/io_uring, I can refine it and follow up with a PR.
extend user data from short to long pr
transport/io_uringcurrently narrows io_uringuser_datafrom its native 64-bit field toshort.This makes one-shot operation tracking unnecessarily restrictive. A dedicated
DefaultIoUringIoRegistrationper op is too expensive, while limiting completion correlation toshortforces awkward sharding across multiple registrations perEventLoopas the available space is exhausted.(it cannot even reliably carry values such as an fd.)We should support
longuser data in the io_uring path to remove this artificial limit and make shared registration reuse scale better.One possible direction is to assign each submitted op a sequence number and keep the op-specific state, such as the original user data and associated
IoRegistration, in a separate tracking structure.I already have an initial implementation that supports this use case. If this direction aligns with Netty's plans for
transport/io_uring, I can refine it and follow up with a PR.extend user data from short to long pr