On Tue, Jun 30, 2026 at 4:06 PM Jakub Kicinski <[email protected]> wrote: > > On Tue, 30 Jun 2026 10:38:01 -0700 Mina Almasry wrote: > > > > 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
