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.
