The Other Direction
RSS, RPS, and RFS all address the receive path — packets coming into the machine. The transmit path (packets going out) has its own scaling challenge.
Without transmit-side optimization, multiple cores might contend for the same TX queue. If Core 0 and Core 2 both try to enqueue packets simultaneously, they must serialize access with a lock, creating contention that limits throughput.
XPS (Transmit Packet Steering), introduced in kernel 2.6.38, solves this by creating a mapping from CPU cores to TX queues. When a core wants to transmit a packet, XPS directs it to a TX queue that is "owned" by that core, avoiding lock contention entirely.
Configuration is similar to RPS but on the TX side: each TX queue's xps_cpus file (under that queue's sysfs directory) is written with the bitmask of the core(s) allowed to use it.
XPS also improves TCP performance specifically: when a core both receives and transmits for the same connection (which RFS encourages), XPS ensures the ACK packets go out on a TX queue owned by that same core. This keeps the entire connection lifecycle — receive, process, transmit — on a single core, maximizing cache locality in both directions.
The full picture of a well-tuned system looks like this: RSS distributes incoming flows across NIC queues → RFS steers each flow to the core running its application → XPS ensures that core's outgoing packets use a dedicated TX queue. Together, these mechanisms allow a single server to saturate a 100 Gbps NIC across all available cores with minimal inter-core coordination.