af_xdp.rst - OpenGrok cross reference for /kernel/linux/linux-5.10/Documentation/networking/af

Lines Matching full:and
13 This document assumes that the reader is familiar with BPF and XDP. If
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
26 packets on the TX ring. These rings are registered and sized with the
27 setsockopts XDP_RX_RING and XDP_TX_RING, respectively. It is mandatory
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
33 to that packet can be changed to point to another and reused right
42 UMEM also has two rings: the FILL ring and the COMPLETION ring. The
47 kernel has transmitted completely and can now be used again by user
50 TX ring. In summary, the RX and FILL rings are used for the RX path
51 and the TX and COMPLETION rings are used for the TX path.
53 The socket is then finally bound with a bind() call to a device and a
54 specific queue id on that device, and it is not until bind is
58 wants to do this, it simply skips the registration of the UMEM and its
60 call and submits the XSK of the process it would like to share UMEM
65 process has to create its own socket with associated RX and TX rings,
67 reason that there is only one set of FILL and COMPLETION rings per
74 this map and at this point XDP validates that the XSK in that map was
75 indeed bound to that device and ring number. If not, the packet is
78 program loaded (and one XSK in the XSKMAP) to be able to get any
81 AF_XDP can operate in two different modes: XDP_SKB and XDP_DRV. If the
84 together with the generic XDP support and copies out the data to user
94 to be setup. These objects and their options are explained in the
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,
111 headroom, start address and size) by using the XDP_UMEM_REG setsockopt
112 system call. A UMEM is bound to a netdev and queue id, via the bind()
118 struct sockaddr_xdp member sxdp_flags, and passing the file descriptor
122 to transfer ownership of UMEM frames between the kernel and the
128 There are a four different kind of rings: FILL, COMPLETION, RX and
133 The UMEM uses two rings: FILL and COMPLETION. Each socket associated
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.
140 producer member, and increasing the producer index. A consumer reads
142 member, and increasing the consumer index.
144 The rings are configured and created via the _RING setsockopt system
145 calls and mmapped to user-space using the appropriate offset to mmap()
146 (XDP_PGOFF_RX_RING, XDP_PGOFF_TX_RING, XDP_UMEM_PGOFF_FILL_RING and
156 an example, if the UMEM is 64k and each chunk is 4k, then the UMEM has
157 16 chunks and can pass addrs between 0 and 64k.
164 the addr will be masked off, meaning that 2048, 2050 and 3000 refers
177 sent (TX ring) and can be used by user-space again.
187 (addr) and the length of the data (len).
199 filled (index, length and offset) and passed into the ring.
210 Libbpf is a helper library for eBPF and XDP that makes using these
214 setup of AF_XDP socket easier and ones that can be used in the data
215 plane to access the rings safely and quickly. To see an example on how
217 samples/bpf/xdpsock_usr.c which uses libbpf for both setup and data
234 not match the queue configuration and netdev, the frame will be
235 dropped. E.g. an AF_XDP socket is bound to netdev eth0 and
236 queue 17. Only the XDP program executing for eth0 and queue 17 will
240 Configuration Flags and Socket Options
244 and monitor the behavior of AF_XDP sockets.
246 XDP_COPY and XDP_ZERO_COPY bind flags
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
264 rings as usual, but you are going to have one or more FILL and
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
270 fist socket created) will only have a single FILL ring and a single
272 we have bound to. To use this mode, create the first socket and bind
273 it in the normal way. Create a second socket and create an RX and a TX
276 XDP_SHARED_UMEM option and provide the initial socket's fd in the
281 program. Put all the sockets in the XSK_MAP and just indicate which
308 Note, that since there is only a single set of FILL and COMPLETION
309 rings, and they are single producer, single consumer rings, you need
317 xsk_socket__create calls and load your own XDP program as there is no
321 bound to different queue ids and/or netdevs. In this case you have to
322 create one FILL ring and one COMPLETION ring for each unique
325 and bind it in the normal way. Create a second socket and create an RX
326 and a TX ring, or at least one of them, and then one FILL and
328 XDP_SHARED_UMEM option and provide the initial socket's fd in the
330 socket. These two sockets will now share one and the same UMEM.
333 case where sockets were bound to the same queue id and
340 takes a reference to a FILL ring and a COMPLETION ring that will be
341 created for you and bound to the shared UMEM. You can use this
343 second and following ones and use xsk_socket__create() for the first
347 and device, as well as between queues on the same device and between
354 present in the FILL ring and the TX ring, the rings for which user
363 more buffers on the FILL ring and no buffers left on the RX HW ring of
365 receive any packets (as there are no buffers to put them in), and the
367 FILL ring and then call poll() so that the kernel driver can put these
368 buffers on the HW ring and start to receive packets.
387 better performance especially if you run the application and the
389 application and the kernel driver, as it reduces the number of
396 FILL, and COMPLETION rings respectively should have. It is mandatory
397 to set the size of at least one of the RX and TX rings. If you set
398 both, you will be able to both receive and send traffic from your
400 resources by only setting up one of them. Both the FILL ring and the
403 first one does not have a UMEM and should in that case not have any
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
415 going to receive something when you in fact will not, and this can
423 pointer to the beginning of this area and the size of it. Moreover, it
426 UMEM area that is 128K and a chunk size of 2K, this means that you
428 area and that your largest packet size can be 2K.
460 user-space application and the XDP program. For a complete setup and
462 side is xdpsock_user.c and the XDP side is part of libbpf.
480 A simple but not so performance ring dequeue and enqueue could look
532 But please use the libbpf functions as they are optimized and ready to
552 For XDP_SKB mode, use the switch "-S" instead of "-N" and all options
555 This sample application uses libbpf to make the setup and usage of
566    allocates one RX and TX queue pair per core. So on a 8 core system,
569    specify a specific queue id to bind to and it is only the traffic
579    id 0, and then bind to queue 0. You can use ethtool to do this::
586    UDP traffic to and from port 4242 are sent to queue 2::
601    sockets bound to different queue ids, for example X and Y, but only
605    traffic to the correct queue id and socket.
611    same buffer into the FILL ring and the TX ring at the same time, the