Receive Side Scaling Distributes Network Flows Across CPU Queues
A fast network adapter can receive packets faster than one processor core can handle them efficiently. Receive Side Scaling, commonly abbreviated RSS, spreads incoming traffic across multiple hardware receive queues. Each queue can be associated with a different processor, allowing packet processing to run in parallel.
RSS usually assigns packets by flow rather than distributing every packet independently. This preserves useful ordering properties while still spreading many simultaneous connections across available queues.
A hash selects the receive queue
The adapter extracts selected fields from each incoming packet and feeds them into a hash function. Common inputs include source and destination IP addresses plus transport-layer port numbers for TCP or UDP traffic.
The resulting hash value is mapped through an indirection table to a receive queue. Drivers can configure that table so queue assignments reflect the processors available to the networking stack.
Packets with the same selected header fields produce the same hash result under a stable configuration. They therefore tend to arrive on the same receive queue instead of bouncing between processors.
Per-flow steering protects packet locality
Sending adjacent packets from one connection to different queues could increase synchronization and cache traffic between processor cores. It could also complicate packet ordering before higher network layers process the stream.
Flow-based steering keeps a connection’s receive work concentrated on one queue. Other connections can map to other queues, giving the system parallelism across flows without splitting each flow across cores by default.
This design works especially well when a server handles many active connections. A single high-rate flow can still be limited by the processing capacity associated with its assigned queue, because RSS does not automatically divide one flow across every core.
The indirection table controls distribution
The RSS indirection table maps hash results to queues. A driver or operating system can alter this mapping to use a subset of queues, change processor affinity, or rebalance traffic.
Uniform table entries do not guarantee uniform workload. Real traffic can contain a few dominant flows, and those flows may hash to the same queue. Queue counters can reveal this imbalance even when the table itself appears evenly configured.
Some systems also support additional steering mechanisms above or beside RSS. Those mechanisms can move selected flows based on observed workload, policy, or application placement.
Queue affinity affects cache behavior
A receive queue commonly triggers interrupts or polling work on a selected processor. Keeping queue processing on a consistent core can improve cache locality because packet descriptors, protocol state, and application data may remain closer to the processor handling that traffic.
Poor affinity can erase part of the benefit. If interrupts arrive on one processor while protocol or application work repeatedly migrates elsewhere, the system can spend more time moving cache lines and coordinating between cores.
RSS tuning therefore involves more than increasing the queue count. Queue-to-processor placement, interrupt settings, NUMA topology, and workload shape can all affect the result.
More queues have a practical limit
Additional receive queues create more opportunities for parallel processing, but each queue also consumes descriptors, interrupt state, and driver resources. A queue count far above the useful processor count may add overhead without increasing throughput.
Virtual machines and containers can add another layer of queue mapping. A physical adapter may steer traffic into hardware queues while a virtual networking layer performs its own distribution before packets reach a guest or workload.
The useful configuration is the one that keeps receive work distributed without excessive coordination. Queue statistics, processor utilization, interrupt placement, and application throughput provide concrete signals for checking that balance.
RSS turns packet classification in the network adapter into a CPU-scaling mechanism. Its hash and indirection table keep individual flows relatively stable while allowing many flows to use multiple receive queues and processor cores in parallel.