The Single-Core Bottleneck
In early multi-core systems, all network receive interrupts were handled by a single CPU core—typically Core 0. The NIC would fire all its interrupts at Core 0, which would process every incoming packet. As network speeds increased to 10Gbps and beyond, Core 0 would saturate at 100% utilization while the other 15 cores sat idle. The network card was fast; the single-core processing path was not.
Receive Side Scaling (RSS) is a NIC hardware feature that solves this by distributing incoming packets across multiple hardware receive queues, with each queue mapped to a different CPU core.
How RSS Works
When a packet arrives, the NIC computes a hash over the packet's 4-tuple: source IP address, destination IP address, source port, destination port. This hash deterministically maps the packet to one of the NIC's hardware receive queues. Each queue has its own interrupt vector, which is assigned to a specific CPU core (configured via /proc/irq/<N>/smp_affinity).
The hash is designed so that all packets belonging to the same TCP connection always hash to the same queue and therefore the same CPU core. This is critical: if packets from the same connection were processed on different cores, you would need expensive cross-core locking to maintain TCP state. RSS avoids this by keeping per-connection processing on a single core while distributing different connections across all cores.
Verifying and Configuring RSS
The number of configured RSS queues, and which CPU core each queue's interrupt is pinned to, are both inspectable — the former via the NIC driver's own reporting, the latter by reading the kernel's live interrupt counters. The number of RSS queues is typically set to match the number of CPU cores, up to the NIC's hardware maximum. On cloud instances, the NIC driver often configures this automatically.
Key Point: RSS distributes network processing across multiple CPU cores by hashing each packet's 4-tuple to a hardware queue. It scales receive throughput linearly with core count while preserving per-connection CPU locality—a requirement for lock-free TCP state management.