While we've added support for Receive Packet Steering (RPS), some NICs support an even more efficient mechanism known as Receive Side Scaling (RSS). This is sometimes referred to as "ntuple" support, or on Intel X550 NICs Intel markets this as "flow director".
With RPS/RFS, the kernel hashes every packet early in the interrupt handler then quickly redirects it to another CPU core. This requires two interrupts, one from the NIC on whatever queue it decided to route the packet into, and another inter-processor interrupt for the kernel to wake up the CPU that is re-assigned to handle the packet.
With RSS, the NIC hardware hashes the flow and directs packets into a particular receive queue based on the flow. With interrupts configured to match, packets get steered directly to the target CPU to process them without the extra indirection/interrupt.
For users who also want to use RFS, enabling the ntuple mode may allow the kernel to use "accelerated RFS" with certain NICs: https://docs.kernel.org/networking/scaling.html#accelerated-rfs (note that out-of-tree Intel drivers VyOS prefers don't seem to implement the requisite function outside of the newest `ice` driver, in-tree drivers do).
Implementation should roughly consist of adding an `offload rss` setting that calls `ethtool -K ethX ntuple [on|off]`. From what I can tell, we don't explicitly go out of our way to configure driver RX queue interrupts today. At least on my 12-core Intel C3858 system, the NICs were configured with 12 RX queues each set to interrupt on one core 1-12, with queue 0 starting with a different CPU for each interface. If we want to match our RPS implementation (which excludes CPU0), we may need to explore re-configuring the NIC queue count and the queue `smp_affinity` settings.
Future work could include exposing more tunables around which CPUs handle receive packets, as well as exposing settings of various NICs around how different packets are hashed (see `ethtool --config-ntuple`).