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. 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. Can y'all not open a pidfs fd for the NAPI thread? You'll get a notification when the existing kthread dies?
