Lines Matching +full:queue +full:- +full:rx
1 .. SPDX-License-Identifier: GPL-2.0
20 XDP programs to redirect frames to a memory buffer in a user-space
24 syscall. Associated with each XSK are two rings: the RX ring and the
25 TX ring. A socket can receive packets on the RX ring and it can send
28 to have at least one of these rings for each socket. An RX or TX
30 UMEM. RX and TX can share the same UMEM so that a packet does not have
31 to be copied between RX and TX. Moreover, if a packet needs to be kept
44 to fill in with RX packet data. References to these frames will then
45 appear in the RX ring once each packet has been received. The
48 space, for either TX or RX. Thus, the frame addrs appearing in the
50 TX ring. In summary, the RX and FILL rings are used for the RX path
54 specific queue id on that device, and it is not until bind is
62 then receive frame addr references in its own RX ring that point to
64 single-consumer / single-producer (for performance reasons), the new
65 process has to create its own socket with associated RX and TX rings,
72 user-space application can place an XSK at an arbitrary place in this
99 http://vger.kernel.org/lpc_net2018_talks/lpc18_paper_af_xdp_perf-v2.pdf. Do
106 ----
109 equal-sized frames. An UMEM is associated to a netdev and a specific
110 queue id of that netdev. It is created and configured (chunk size,
112 system call. A UMEM is bound to a netdev and queue id, via the bind()
121 The UMEM has two single-producer/single-consumer rings that are used
123 user-space application.
126 -----
128 There are a four different kind of rings: FILL, COMPLETION, RX and
129 TX. All rings are single-producer/single-consumer, so the user-space
134 with the UMEM must have an RX queue, TX queue or both. Say, that there
135 is a setup with four sockets (all doing TX and RX). Then there will be
136 one FILL ring, one COMPLETION ring, four TX rings and four RX rings.
145 calls and mmapped to user-space using the appropriate offset to mmap()
155 user-space to kernel-space. The UMEM addrs are passed in the ring. As
159 Frames passed to the kernel are used for the ingress path (RX rings).
173 kernel-space to user-space. Just like the FILL ring, UMEM indices are
176 Frames passed from the kernel to user-space are frames that has been
177 sent (TX ring) and can be used by user-space again.
182 RX Ring
185 The RX ring is the receiving side of a socket. Each entry in the ring
190 descriptors will (or can) appear on the RX ring.
234 not match the queue configuration and netdev, the frame will be
236 queue 17. Only the XDP program executing for eth0 and queue 17 will
247 ------------------------------------
249 When you bind to a socket, the kernel will first try to use zero-copy
250 copy. If zero-copy is not supported, it will fall back on using copy
256 socket into zero-copy mode or fail.
259 -------------------------
262 works on the same queue id, between queue ids and between
263 netdevs/devices. In this mode, each socket has their own RX and TX
266 unique netdev and queue id tuple that you bind to.
269 sockets bound to the same netdev and queue id. The UMEM (tied to the
273 it in the normal way. Create a second socket and create an RX and a TX
283 round-robin example of distributing packets is shown below:
285 .. code-block:: c
303 rr = (rr + 1) & (MAX_SOCKS - 1);
321 bound to different queue ids and/or netdevs. In this case you have to
324 to two different queue ids on the same netdev. Create the first socket
325 and bind it in the normal way. Create a second socket and create an RX
333 case where sockets were bound to the same queue id and
335 the packets to the right queue. In the previous example, there is only
336 one queue shared among sockets, so the NIC cannot do this steering. It
346 Note that a UMEM can be shared between sockets on the same queue id
351 -----------------------------
361 poll() to be able to continue to receive packets on the RX ring. This
363 more buffers on the FILL ring and no buffers left on the RX HW ring of
373 RX path, or by calling sendto().
379 .. code-block:: c
392 XDP_{RX|TX|UMEM_FILL|UMEM_COMPLETION}_RING setsockopts
393 ------------------------------------------------------
395 These setsockopts sets the number of descriptors that the RX, TX,
397 to set the size of at least one of the RX and TX rings. If you set
405 be used. Note, that the rings are single-producer single-consumer, so
409 In libbpf, you can create Rx-only and Tx-only sockets by supplying
410 NULL to the rx and tx arguments, respectively, to the
413 If you create a Tx-only socket, we recommend that you do not put any
419 -----------------------
437 -------------------------
442 .. code-block:: c
451 ----------------------
454 XDP_OPTIONS_ZEROCOPY which tells you if zero-copy is on or not.
460 user-space application and the XDP program. For a complete setup and
461 usage example, please refer to the sample application. The user-space
466 .. code-block:: c
470 int index = ctx->rx_queue_index;
483 .. code-block:: c
505 __u32 entries = *ring->producer - *ring->consumer;
508 return -1;
510 // read-barrier!
512 *item = ring->desc[*ring->consumer & (RING_SIZE - 1)];
513 (*ring->consumer)++;
519 u32 free_entries = RING_SIZE - (*ring->producer - *ring->consumer);
522 return -1;
524 ring->desc[*ring->producer & (RING_SIZE - 1)] = *item;
526 // write-barrier!
528 (*ring->producer)++;
540 you would like your UDP traffic from port 4242 to end up in queue 16,
543 ethtool -N p3p2 rx-flow-hash udp4 fn
544 ethtool -N p3p2 flow-type udp4 src-port 4242 dst-port 4242 \
550 samples/bpf/xdpsock -i p3p2 -q 16 -r -N
552 For XDP_SKB mode, use the switch "-S" instead of "-N" and all options
553 can be displayed with "-h", as usual.
566 allocates one RX and TX queue pair per core. So on a 8 core system,
567 queue ids 0 to 7 will be allocated, one per core. In the AF_XDP
569 specify a specific queue id to bind to and it is only the traffic
570 towards that queue you are going to get on you socket. So in the
571 example above, if you bind to queue 0, you are NOT going to get any
577 traffic you want to the queue id you bound to. If you want to see
578 all the traffic, you can force the netdev to only have 1 queue, queue
579 id 0, and then bind to queue 0. You can use ethtool to do this::
581 sudo ethtool -L <interface> combined 1
584 NIC through ethtool to filter out your traffic to a single queue id
586 UDP traffic to and from port 4242 are sent to queue 2::
588 sudo ethtool -N <interface> rx-flow-hash udp4 fn
589 sudo ethtool -N <interface> flow-type udp4 src-port 4242 dst-port \
599 XSKMAP can only be used to switch traffic coming in on queue id X
600 to sockets bound to the same queue id X. The XSKMAP can contain
601 sockets bound to different queue ids, for example X and Y, but only
602 traffic goming in from queue id Y can be directed to sockets bound
603 to the same queue id Y. In zero-copy mode, you should use the
605 traffic to the correct queue id and socket.
615 belonging to different queue ids or netdevs bound with the
621 - Björn Töpel (AF_XDP core)
622 - Magnus Karlsson (AF_XDP core)
623 - Alexander Duyck
624 - Alexei Starovoitov
625 - Daniel Borkmann
626 - Jesper Dangaard Brouer
627 - John Fastabend
628 - Jonathan Corbet (LWN coverage)
629 - Michael S. Tsirkin
630 - Qi Z Zhang
631 - Willem de Bruijn