Re: [PATCH net-next v1 0/2] Reuse threaded NAPI kthread across napi_del()/napi_add().

On Tue, Jun 30, 2026 at 4:06 PM Jakub Kicinski [off-list ref] wrote:

On Tue, 30 Jun 2026 10:38:01 -0700 Mina Almasry wrote:

quoted

quoted

quoted

It feels surprising that the userspace needs to reconfigure thread
properties when changing NIC configurations unrelated to threading.
Another downside is that when userspace configures NIC configurations
in quick succession, re-application becomes messy because a previous
re-application might still be in progress when the thread is gone.

Can you explain more about your deployment and system configuration
flow? We may be adding micro optimizations when the problem is that
we recreate the NAPIs in the first place.

We have an AF_XDP application with extremely low latency and jitter
requirements running on our servers. Sami developed busypolling
threaded napi for them. Since it's an AF_XDP application, they attach
their umem to specific RX queues, and then configure threaded NAPI
busypolling to achieve low latency. That involves using the Netlink
API to set the threaded/busypolling property, grabbing the kthread
PID, and setting some properties on the kthread.

What I don't understand is how you have an "application with extremely
low latency and jitter requirements" and at the same time "user runs
an unrelated ethtool command" reallocating NAPIs and disrupting that
application.

It is unlikely. However, if someone intentionally or accidentally
triggers a NAPI reallocation, it should only be disruptive while it is
happening, not leave the application running in a degraded state for
the rest of the workload run. Right now it feels like the user must be
very careful. There are also link down/up events outside the user's
control, which should not happen, but if they do, minimizing their
impact would be nice.

Honestly, the last two times y'all were touching NAPI it was a major
effort to get the code into acceptable shape. I don't have the cycles
right now to help another unknown-upstream (intern?) get their patches
into shape.

My sincere apologies. I also did not do a good job of not taxing your
time with the devmem stuff. FWIW I reviewed this before it was sent,
but I didn't think my Reviewed-by would move the needle much. We can
block future iterations until we get reviewed-bys from Willem or
Kuniyuki.

Can y'all not open a pidfs fd for the NAPI thread? You'll get a
notification when the existing kthread dies?

Let me take a look, but I think we need a notification when the
kthread is back up to reconfigure it. I guess if we're trying very
hard not to touch the current code we can always monitor the running
napi kthreads and their affinity and work around it like that.

-- 
Thanks,
Mina