Lines Matching refs:queue

24 (multi-queue). On reception, a NIC can send different packets to different
28 queue, which in turn can be processed by separate CPUs. This mechanism is
31 Multi-queue distribution can also be used for traffic prioritization, but
38 stores a queue number. The receive queue for a packet is determined
45 can be directed to their own receive queue. Such “n-tuple” filters can
50 The driver for a multi-queue capable NIC typically provides a kernel
53 num_queues. A typical RSS configuration would be to have one receive queue
58 The indirection table of an RSS device, which resolves a queue by masked
68 Each receive queue has a separate IRQ associated with it. The NIC triggers
69 this to notify a CPU when new packets arrive on the given queue. The
84 decreases queue length. For low latency networking, the optimal setting
88 receive queue overflows due to a saturated CPU, because in default
90 interrupts (and thus work) grows with each additional queue.
104 Whereas RSS selects the queue and hence CPU that will run the hardware
107 on the desired CPU’s backlog queue and waking up the CPU for processing.
116 selects the queue that should process a packet.
128 Each receive hardware queue has an associated list of CPUs to which
132 and the packet is queued to the tail of that CPU’s backlog queue. At
134 packets have been queued to their backlog queue. The IPI wakes backlog
143 can be configured for each receive queue using a sysfs file entry:
154 For a single queue device, a typical RPS configuration would be to set
160 For a multi-queue system, if RSS is configured so that a hardware
161 receive queue is mapped to each CPU, then RPS is probably redundant
163 RPS might be beneficial if the rps_cpus for each queue are the ones that
164 share the same memory domain as the interrupting CPU for that queue.
180 queue exceeds half the maximum queue length (as set by sysctl
185 dropped once the input packet queue reaches netdev_max_backlog.
186 No packets are dropped when the input packet queue length is below
219 The feature depends on the input packet queue length to exceed
257 receive queue of each device. Each table value stores a CPU index and a
267 queue has a head counter that is incremented on dequeue. A tail counter
268 is computed as head counter + queue length. In other words, the counter
276 and the rps_dev_flow table of the queue that the packet was received on
283 - The current CPU's queue head counter >= the recorded tail counter
302 The number of entries in the per-queue flow table are set through:
308 Both of these need to be set before RFS is enabled for a receive queue.
315 For a single queue device, the rps_flow_cnt value for the single queue
317 For a multi-queue device, the rps_flow_cnt for each queue might be
320 are 16 configured receive queues, rps_flow_cnt for each queue might be
337 queue for packets matching a particular flow. The network stack
342 The hardware queue for a flow is derived from the CPU recorded in
343 rps_dev_flow_table. The stack consults a CPU to hardware queue map which
347 to populate the map. For each CPU, the corresponding queue in the map is
356 configured for each receive queue by the driver, so no additional
368 which transmit queue to use when transmitting a packet on a multi-queue
369 device. To accomplish this, a mapping from CPU to hardware queue(s) is
373 provides two benefits. First, contention on the device queue lock is
374 significantly reduced since fewer CPUs contend for the same queue
376 transmit queue). Secondly, cache miss rate on transmit completion is
380 XPS is configured per transmit queue by setting a bitmap of CPUs that
381 may use that queue to transmit. The reverse mapping, from CPUs to
384 get_xps_queue() is called to select a queue. This function uses the ID
385 of the running CPU as a key into the CPU-to-queue lookup table. If the
386 ID matches a single queue, that is used for transmission. If multiple
390 The queue chosen for transmitting a particular flow is saved in the
392 This transmit queue is used for subsequent packets sent on the flow to
395 ooo packets, the queue for a flow can subsequently only be changed if
397 there are no outstanding packets in the flow, so the transmit queue can
408 queue is configured using the sysfs file entry:
414 For a network device with a single transmission queue, XPS configuration
415 has no effect, since there is no choice in this case. In a multi-queue
416 system, XPS is preferably configured so that each CPU maps onto one queue.
418 queue can also map onto one CPU, resulting in exclusive pairings that
420 best CPUs to share a given queue are probably those that share the cache
421 with the CPU that processes transmit completions for that queue