Documentation/networking/scaling.rst

17 - RSS: Receive Side Scaling
18 - RPS: Receive Packet Steering
19 - RFS: Receive Flow Steering
20 - Accelerated Receive Flow Steering
24 RSS: Receive Side Scaling
27 Contemporary NICs support multiple receive and transmit descriptor queues
31 of logical flows. Packets for each flow are steered to a separate receive
33 generally known as “Receive-side Scaling” (RSS). The goal of RSS and
42 stores a queue number. The receive queue for a packet is determined
49 can be directed to their own receive queue. Such “n-tuple” filters can
59 num_queues. A typical RSS configuration would be to have one receive queue
76 Each receive queue has a separate IRQ associated with it. The NIC triggers
82 processing takes place in receive interrupt handling, it is advantageous
83 to spread receive interrupts between CPUs. To manually adjust the IRQ
92 RSS should be enabled when latency is a concern or whenever receive
97 is likely the one with the smallest number of receive queues where no
98 receive queue overflows due to a saturated CPU, because in default
109 RPS: Receive Packet Steering
112 Receive Packet Steering (RPS) is logically a software implementation of
125 RPS is called during bottom half of the receive interrupt handler, when
135 the receive descriptor for the packet; this would usually be the same
140 Each receive hardware queue has an associated list of CPUs to which
157 can be configured for each receive queue using a sysfs file entry::
177 receive queue is mapped to each CPU, then RPS is probably redundant
186 RPS scales kernel receive processing across CPUs without introducing
247 RFS: Receive Flow Steering
252 application locality. This is accomplished by Receive Flow Steering
276 receive packets on the old CPU, packets may arrive out of order. To
279 receive queue of each device. Each table value stores a CPU index and a
334 Both of these need to be set before RFS is enabled for a receive queue.
346 are 16 configured receive queues, rps_flow_cnt for each queue might be
384 configured for each receive queue by the driver, so no additional
401 a mapping of CPU to hardware queue(s) or a mapping of receive queue(s)
416 2. XPS using receive queues map
418 This mapping is used to pick transmit queue based on the receive
419 queue(s) map configuration set by the administrator. A set of receive
422 on the same queue associations for transmit and receive. This is useful for
426 received on a single queue. The receive queue number is cached in the
428 transmit queue corresponding to the associated receive queue has benefits
437 CPUs/receive-queues that may use that queue to transmit. The reverse
438 mapping, from CPUs to transmit queues or from receive-queues to transmit
441 called to select a queue. This function uses the ID of the receive queue
442 for the socket connection for a match in the receive queue-to-transmit queue
447 into the set. When selecting the transmit queue based on receive queue(s)
448 map, the transmit device is not validated against the receive device as it
469 how, XPS is configured at device init. The mapping of CPUs/receive-queues
476 For selection based on receive-queues map::
494 For transmit queue selection based on receive queue(s), XPS has to be
495 explicitly configured mapping receive-queue(s) to transmit queue(s). If the
496 user configuration for receive-queue map does not apply, then the transmit