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
71 can be directed to their own receive queue. Such “n-tuple” filters can
81 num_queues. A typical RSS configuration would be to have one receive queue
98 Each receive queue has a separate IRQ associated with it. The NIC triggers
104 processing takes place in receive interrupt handling, it is advantageous
105 to spread receive interrupts between CPUs. To manually adjust the IRQ
114 RSS should be enabled when latency is a concern or whenever receive
119 is likely the one with the smallest number of receive queues where no
120 receive queue overflows due to a saturated CPU, because in default
173 RPS: Receive Packet Steering
176 Receive Packet Steering (RPS) is logically a software implementation of
189 RPS is called during bottom half of the receive interrupt handler, when
199 the receive descriptor for the packet; this would usually be the same
204 Each receive hardware queue has an associated list of CPUs to which
221 can be configured for each receive queue using a sysfs file entry::
241 receive queue is mapped to each CPU, then RPS is probably redundant
250 RPS scales kernel receive processing across CPUs without introducing
311 RFS: Receive Flow Steering
316 application locality. This is accomplished by Receive Flow Steering
340 receive packets on the old CPU, packets may arrive out of order. To
343 receive queue of each device. Each table value stores a CPU index and a
398 Both of these need to be set before RFS is enabled for a receive queue.
410 are 16 configured receive queues, rps_flow_cnt for each queue might be
450 configured for each receive queue by the driver, so no additional
467 a mapping of CPU to hardware queue(s) or a mapping of receive queue(s)
482 2. XPS using receive queues map
484 This mapping is used to pick transmit queue based on the receive
485 queue(s) map configuration set by the administrator. A set of receive
488 on the same queue associations for transmit and receive. This is useful for
492 received on a single queue. The receive queue number is cached in the
494 transmit queue corresponding to the associated receive queue has benefits
503 CPUs/receive-queues that may use that queue to transmit. The reverse
504 mapping, from CPUs to transmit queues or from receive-queues to transmit
507 called to select a queue. This function uses the ID of the receive queue
508 for the socket connection for a match in the receive queue-to-transmit queue
513 into the set. When selecting the transmit queue based on receive queue(s)
514 map, the transmit device is not validated against the receive device as it
535 how, XPS is configured at device init. The mapping of CPUs/receive-queues
542 For selection based on receive-queues map::
560 For transmit queue selection based on receive queue(s), XPS has to be
561 explicitly configured mapping receive-queue(s) to transmit queue(s). If the
562 user configuration for receive-queue map does not apply, then the transmit