Check out my first novel, midnight's simulacra!

RSS: Difference between revisions

From dankwiki
(Created page with "Receiver-Side Scaling is a function of some NICs where traffic is divided into one or more hardware RX queues, each with their own MSI. These MSI numbers can then be associated with different cores, creating parallelism in network interrupt handling. If the device must not reorder traffic within a flow, it is generally necessary that all packets from the same flow hit the same core, so the RX queue is typically chosen via a hash over the L3 and L4 addresses. This mea...")
 
No edit summary
 
Line 2: Line 2:


The idea behind RSS can be performed in Linux's softirq handler, where it is called RPS (Receive Packet Steering) or RFS (Receive Flow Steering). RPS works by distributing to cores according to their queue length. RFS hashes source L3 addresses to cores. Either way, software steering will run on the core designated by the MSI (and thus the RX queue). RSS can thus usually more fully exploit parallelism (because the hard and softirq handlers themselves can be paralellized), and it is not usually useful to use RFS/RPS in conjunction with RSS (this might not be the case if there are more cores available than RX queues).
The idea behind RSS can be performed in Linux's softirq handler, where it is called RPS (Receive Packet Steering) or RFS (Receive Flow Steering). RPS works by distributing to cores according to their queue length. RFS hashes source L3 addresses to cores. Either way, software steering will run on the core designated by the MSI (and thus the RX queue). RSS can thus usually more fully exploit parallelism (because the hard and softirq handlers themselves can be paralellized), and it is not usually useful to use RFS/RPS in conjunction with RSS (this might not be the case if there are more cores available than RX queues).
[[CATEGORY: Hardware]]

Latest revision as of 03:56, 18 April 2023

Receiver-Side Scaling is a function of some NICs where traffic is divided into one or more hardware RX queues, each with their own MSI. These MSI numbers can then be associated with different cores, creating parallelism in network interrupt handling. If the device must not reorder traffic within a flow, it is generally necessary that all packets from the same flow hit the same core, so the RX queue is typically chosen via a hash over the L3 and L4 addresses. This means that there must be sufficient flow divergence to spread the traffic evenly across queues; if the traffic is dominated by a single flow, a single core will receive the majority of the work.

The idea behind RSS can be performed in Linux's softirq handler, where it is called RPS (Receive Packet Steering) or RFS (Receive Flow Steering). RPS works by distributing to cores according to their queue length. RFS hashes source L3 addresses to cores. Either way, software steering will run on the core designated by the MSI (and thus the RX queue). RSS can thus usually more fully exploit parallelism (because the hard and softirq handlers themselves can be paralellized), and it is not usually useful to use RFS/RPS in conjunction with RSS (this might not be the case if there are more cores available than RX queues).