On 12/10/24 03:44, Jakub Kicinski wrote:
On Wed, 4 Dec 2024 09:21:47 -0800 David Wei wrote:
It's useful to have napi private bits and pieces like page pool's fast
allocating cache, so that the hot allocation path doesn't have to do any
additional synchronisation. In case of io_uring memory provider
introduced in following patches, we keep the consumer end of the
io_uring's refill queue private to napi as it's a hot path.
However, from time to time we need to synchronise with the napi, for
example to add more user memory or allocate fallback buffers. Add a
helper function napi_execute that allows to run a custom callback from
under napi context so that it can access and modify napi protected
parts of io_uring. It works similar to busy polling and stops napi from
running in the meantime, so it's supposed to be a slow control path.
Let's leave this out, please. I seriously doubt this works reliably
and the bar for adding complexity to NAPI is fairly high. A commit
which doesn't even quote any perf numbers will certainly not clear it.
I reworked it and got rid of the patch, though I don't see why
performance here would matter. It's a very slow path if all
paths failed, batching inside wasn't done right on the io_uring
for simplicity, but that was certainly planned a follow up.
--
Pavel Begunkov
