Lines Matching refs:flow
27 of logical flows. Packets for each flow are steered to a separate receive
119 flow hash over the packet’s addresses or ports (2-tuple or 4-tuple hash
121 associated flow of the packet. The hash is either provided by hardware
126 packet’s flow.
130 an index into the list is computed from the flow hash modulo the size
169 reordering. The trade-off to sending all packets from the same flow
171 In the extreme case a single flow dominates traffic. Especially on
181 net.core.netdev_max_backlog), the kernel starts a per-flow packet
182 count over the last 256 packets. If a flow exceeds a set ratio (by
187 the threshold, so flow limit does not sever connections outright:
200 Per-flow rate is calculated by hashing each packet into a hashtable
203 be much larger than the number of CPUs, flow limit has finer-grained
220 the flow limit threshold (50%) + the flow history length (256).
238 but the hash is used as index into a flow lookup table. This table maps
239 flows to the CPUs where those flows are being processed. The flow hash
241 The CPU recorded in each entry is the one which last processed the flow.
245 a single application thread handles flows with many different flow hashes.
247 rps_sock_flow_table is a global flow table that contains the *desired* CPU
248 for flows: the CPU that is currently processing the flow in userspace.
255 avoid this, RFS uses a second flow table to track outstanding packets
256 for each flow: rps_dev_flow_table is a table specific to each hardware
259 for this flow are enqueued for further kernel processing. Ideally, kernel
266 CPU's backlog when a packet in this flow was last enqueued. Each backlog
269 in rps_dev_flow[i] records the last element in flow i that has
270 been enqueued onto the currently designated CPU for flow i (of course,
277 are compared. If the desired CPU for the flow (found in the
289 CPU. These rules aim to ensure that a flow only moves to a new CPU when
298 configured. The number of entries in the global flow table is set through:
302 The number of entries in the per-queue flow table are set through:
310 suggested flow count depends on the expected number of active connections
329 the application thread consuming the packets of each flow is running.
337 queue for packets matching a particular flow. The network stack
338 automatically calls this function every time a flow entry in
342 The hardware queue for a flow is derived from the CPU recorded in
383 When transmitting the first packet in a flow, the function
387 queues match, one is selected by using the flow hash to compute an index
390 The queue chosen for transmitting a particular flow is saved in the
391 corresponding socket structure for the flow (e.g. a TCP connection).
392 This transmit queue is used for subsequent packets sent on the flow to
394 of calling get_xps_queues() over all packets in the flow. To avoid
395 ooo packets, the queue for a flow can subsequently only be changed if
396 skb->ooo_okay is set for a packet in the flow. This flag indicates that
397 there are no outstanding packets in the flow, so the transmit queue can