Work to reduce the amount of developer involvement in netlink coding has been widely successful[1]. To name a few existing consumers of this new approach: devlink, ethtool, DPLL, FOU, XDP, TLS handshake[2], etc. You essentially define your netlink messaging and attributes in YAML and a compiler outputs not only all the commodity code (parsing, validating, etc) that you would have had to write (and make mistakes in) but also documentation(as you all know: developers like to write documentation. Not)!

In this talk, Amritha Nambiar and Sridhar Samudrala extend the netlink definition of netdev-genl to add support for additional netdev objects: queue and NAPI. Queues are exposed as netlink objects, enabling visibility to per queue attributes (example, NAPI instance servicing the queue, stats, memory model etc.). NAPI instances are used to expose attributes such as the NAPI id, NAPI device, interrupt number associated with the NAPI instance and PID of the NAPI thread.

Amritha and Sridhar say their work opens a lot of opportunities for interesting use cases. Example, the new netlink communication could be used to create queues etc. for multiple usecases (RSS context handling, Rx zerocopy, XDP); adjusting the NAPI thread priorities and SMP affinity. Additionally, with this features in place, one could also configure NAPI pollers to queues from the userspace. This could be used to limit the number of NAPI instances by configuring a poller to be shared among queues that are on an interrupt vector, etc.

In this talk, they will discuss the design and how it interacts with the driver subsystem; they will further discuss challenges faced and their solutions as well as future work.

Come and engage them in the discussion!

[1]https://docs.kernel.org/userspace-api/netlink/specs.html [2]https://netdevconf.info/0x17/sessions/bof/tls-handshake-for-in-kernel-consum...

cheers, jamal