| Message ID | 20250102191227.2084046-1-skhawaja@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support to do threaded napi busy poll | expand |
On 01/02, Samiullah Khawaja wrote: > Extend the already existing support of threaded napi poll to do continuous > busypolling. > > This is used for doing continuous polling of napi to fetch descriptors from > backing RX/TX queues for low latency applications. Allow enabling of threaded > busypoll using netlink so this can be enabled on a set of dedicated napis for > low latency applications. > > Currently threaded napi is only enabled at device level using sysfs. Add > support to enable/disable threaded mode for a napi individually. This can be > done using the netlink interface. Add `set_threaded` op in netlink spec that > allows setting the `threaded` attribute of a napi. > > Extend the threaded attribute in napi struct to add an option to enable > continuous busy polling. Extend the netlink and sysfs interface to allow > enabled/disabling threaded busypolling at device or individual napi level. > > Once threaded busypoll on a napi is enabled, depending on the application > requirements the polling thread can be moved to dedicated cores. We used this > for AF_XDP usecases to fetch packets from RX queues to reduce latency. Joe recently added tools/testing/selftests/net/busy_poller.c, should we extend it to cover your new threaded/non-thread busy/non-busy napi modes?
On Thu, 2 Jan 2025 19:12:24 +0000 Samiullah Khawaja <skhawaja@google.com> wrote: > Extend the already existing support of threaded napi poll to do continuous > busypolling. > > This is used for doing continuous polling of napi to fetch descriptors from > backing RX/TX queues for low latency applications. Allow enabling of threaded > busypoll using netlink so this can be enabled on a set of dedicated napis for > low latency applications. > > Currently threaded napi is only enabled at device level using sysfs. Add > support to enable/disable threaded mode for a napi individually. This can be > done using the netlink interface. Add `set_threaded` op in netlink spec that > allows setting the `threaded` attribute of a napi. > > Extend the threaded attribute in napi struct to add an option to enable > continuous busy polling. Extend the netlink and sysfs interface to allow > enabled/disabling threaded busypolling at device or individual napi level. > > Once threaded busypoll on a napi is enabled, depending on the application > requirements the polling thread can be moved to dedicated cores. We used this > for AF_XDP usecases to fetch packets from RX queues to reduce latency. I think it would be more generally useful to be able to set the priority of the NAPI thread. 'busypolling' is just an extreme version of a high priority thread. We've had to use threaded NAPI and a low SCHED_FIFO priority in order to clear the RX queues without the softint code locking out a other SCHED_FIFO user threads for 20ms+. That is currently rather a pain to setup. David
On Thu, 2 Jan 2025 19:12:24 +0000 Samiullah Khawaja wrote: > Extend the already existing support of threaded napi poll to do continuous > busypolling. > > This is used for doing continuous polling of napi to fetch descriptors from > backing RX/TX queues for low latency applications. Allow enabling of threaded > busypoll using netlink so this can be enabled on a set of dedicated napis for > low latency applications. This is lacking clear justification and experimental results vs doing the same thing from user space. I'd also appreciate if Google could share the experience and results of using basic threaded NAPI _in production_.