Lines Matching full:receive

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
64 can be directed to their own receive queue. Such “n-tuple” filters can
74 num_queues. A typical RSS configuration would be to have one receive queue
91 Each receive queue has a separate IRQ associated with it. The NIC triggers
97 processing takes place in receive interrupt handling, it is advantageous
98 to spread receive interrupts between CPUs. To manually adjust the IRQ
107 RSS should be enabled when latency is a concern or whenever receive
112 is likely the one with the smallest number of receive queues where no
113 receive queue overflows due to a saturated CPU, because in default
166 RPS: Receive Packet Steering
169 Receive Packet Steering (RPS) is logically a software implementation of
182 RPS is called during bottom half of the receive interrupt handler, when
192 the receive descriptor for the packet; this would usually be the same
197 Each receive hardware queue has an associated list of CPUs to which
214 can be configured for each receive queue using a sysfs file entry::
234 receive queue is mapped to each CPU, then RPS is probably redundant
243 RPS scales kernel receive processing across CPUs without introducing
304 RFS: Receive Flow Steering
309 application locality. This is accomplished by Receive Flow Steering
333 receive packets on the old CPU, packets may arrive out of order. To
336 receive queue of each device. Each table value stores a CPU index and a
391 Both of these need to be set before RFS is enabled for a receive queue.
403 are 16 configured receive queues, rps_flow_cnt for each queue might be
441 configured for each receive queue by the driver, so no additional
458 a mapping of CPU to hardware queue(s) or a mapping of receive queue(s)
473 2. XPS using receive queues map
475 This mapping is used to pick transmit queue based on the receive
476 queue(s) map configuration set by the administrator. A set of receive
479 on the same queue associations for transmit and receive. This is useful for
483 received on a single queue. The receive queue number is cached in the
485 transmit queue corresponding to the associated receive queue has benefits
494 CPUs/receive-queues that may use that queue to transmit. The reverse
495 mapping, from CPUs to transmit queues or from receive-queues to transmit
498 called to select a queue. This function uses the ID of the receive queue
499 for the socket connection for a match in the receive queue-to-transmit queue
504 into the set. When selecting the transmit queue based on receive queue(s)
505 map, the transmit device is not validated against the receive device as it
526 how, XPS is configured at device init. The mapping of CPUs/receive-queues
533 For selection based on receive-queues map::
551 For transmit queue selection based on receive queue(s), XPS has to be
552 explicitly configured mapping receive-queue(s) to transmit queue(s). If the
553 user configuration for receive-queue map does not apply, then the transmit