Why One Core Can't Handle Everything
Think of a busy restaurant with a single cashier. No matter how many tables are full, every order goes through that one person. As the restaurant gets busier, the cashier becomes the bottleneck — not because the kitchen is slow, but because the intake point can't keep up. Early network hardware had exactly this problem.
In the original Linux networking model, a Network Interface Card (NIC) had a single receive queue (RX Queue) and a single interrupt line. When a packet arrived, the NIC raised a hardware interrupt, and the CPU's interrupt controller routed that interrupt to exactly one core — almost always CPU Core 0. Core 0 would stop whatever it was doing, run the interrupt handler, pull the packet from the NIC's buffer, and walk it up the entire network stack: Ethernet → IP → TCP → socket buffer → application.
As network speeds grew from 1 Gbps to 10 Gbps to 100 Gbps, the volume of packets per second grew proportionally. A 10 Gbps link carrying minimum-size 64-byte Ethernet frames generates roughly 14.8 million packets per second. Core 0 simply cannot process that many interrupts, parse headers, run netfilter rules, and copy data into socket buffers — all in sequence. Meanwhile, Cores 1 through 63 sit completely idle, waiting for work that the interrupt controller will never send them.
The fundamental problem is that the hardware interrupt model creates a hard coupling between a single NIC queue and a single CPU core. Solving this requires either smarter hardware, smarter software, or both.