Distributing Work Before the OS Sees It
The most efficient place to distribute packet processing is at the hardware level — before the operating system is even involved. Modern NICs implement RSS (Receive Side Scaling) to do exactly this.
With RSS, the NIC contains multiple independent RX Queues (commonly 4, 8, or 16, depending on the hardware). When a packet arrives, the NIC's onboard processor computes a hash over the packet's 4-tuple: Source IP, Destination IP, Source Port, Destination Port. This hash deterministically maps the packet to one of the available queues. Critically, all packets belonging to the same TCP connection always hash to the same queue — preserving per-flow ordering, which TCP requires for correctness.
Each RX Queue is assigned its own MSI-X interrupt vector (Message Signaled Interrupts Extended — a mechanism that lets a PCIe device send interrupts directly to a specific CPU core without going through a shared interrupt controller). The system administrator or driver maps each queue's interrupt to a specific core:
Queue 0 → MSI-X Vector 0 → Core 0
Queue 1 → MSI-X Vector 1 → Core 1
Queue 2 → MSI-X Vector 2 → Core 2
Queue 3 → MSI-X Vector 3 → Core 3
You can inspect and configure this mapping on Linux using the /proc/interrupts file and the irqbalance daemon, or manually by writing a CPU bitmask to /proc/irq/<N>/smp_affinity to pin a given interrupt exclusively to one core.
The result is that the NIC itself acts as a load balancer. By the time the OS kernel's interrupt handler runs, the packet is already on the right core's queue. No inter-core communication is needed.
The hash function used by RSS is typically Toeplitz hashing with a secret key, which can be inspected or reconfigured — including how many queues to distribute across — via ethtool.
Interviewers often ask: "How does RSS guarantee that packets from the same TCP connection are always processed in order?" The answer is that the 4-tuple hash is deterministic — given the same source/destination IP and port pair, the hash always produces the same value, so all packets for a connection always land in the same queue and are processed by the same core sequentially. This is why RSS can scale without breaking TCP's ordering guarantees.