Software Scaling: RPS (Receive Packet Steering)

When the Hardware Can't Help

Not every system has a modern NIC with multiple queues. Cloud VMs frequently expose a single virtual NIC queue regardless of how many vCPUs the instance has. Older or cheaper hardware may simply lack RSS support. In these cases, Linux provides a software equivalent called RPS (Receive Packet Steering), introduced in kernel 2.6.35.

RPS mimics what RSS does in hardware, but entirely in software. Here is the step-by-step flow:

1. A packet arrives. The single hardware queue raises an interrupt, waking Core 0.
2. Core 0's interrupt handler pulls the packet from the NIC ring buffer (the minimum necessary work).
3. Core 0 computes the same 4-tuple hash that RSS would have computed in hardware.
4. Core 0 consults a per-queue CPU bitmask (configured by the administrator) to determine which core should handle this flow. For example, if the hash maps to Core 2, Core 0 enqueues the packet into Core 2's backlog queue (a per-CPU softnet queue).
5. Core 0 sends an IPI (Inter-Processor Interrupt) to Core 2, signaling it to process its backlog.
6. Core 2 wakes up and runs the full network stack processing: IP routing, netfilter, TCP reassembly, socket delivery.

RPS is configured per NIC queue via sysfs: a CPU bitmask written to that queue's rps_cpus file (e.g., f in hex, covering cores 0 through 3) determines which cores are eligible to handle its packets, and the same file can be read back to confirm the current setting.

RPS does not eliminate Core 0's involvement — it still handles the interrupt and the initial hash computation. But it offloads the expensive work (protocol stack traversal, firewall rules, socket buffer management) to other cores. The IPI overhead is real but small compared to the cost of full packet processing.