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 make the setup of AF_XDP socket easier and ones that can be used in the
215 data plane to access the rings safely and quickly.
231 not match the queue configuration and netdev, the frame will be
232 dropped. E.g. an AF_XDP socket is bound to netdev eth0 and
233 queue 17. Only the XDP program executing for eth0 and queue 17 will
237 Configuration Flags and Socket Options
241 and monitor the behavior of AF_XDP sockets.
243 XDP_COPY and XDP_ZEROCOPY bind flags
259 works on the same queue id, between queue ids and between
260 netdevs/devices. In this mode, each socket has their own RX and TX
261 rings as usual, but you are going to have one or more FILL and
263 unique netdev and queue id tuple that you bind to.
266 sockets bound to the same netdev and queue id. The UMEM (tied to the
267 fist socket created) will only have a single FILL ring and a single
269 we have bound to. To use this mode, create the first socket and bind
270 it in the normal way. Create a second socket and create an RX and a TX
273 XDP_SHARED_UMEM option and provide the initial socket's fd in the
278 program. Put all the sockets in the XSK_MAP and just indicate which
305 Note, that since there is only a single set of FILL and COMPLETION
306 rings, and they are single producer, single consumer rings, you need
314 xsk_socket__create calls and load your own XDP program as there is no
318 bound to different queue ids and/or netdevs. In this case you have to
319 create one FILL ring and one COMPLETION ring for each unique
322 and bind it in the normal way. Create a second socket and create an RX
323 and a TX ring, or at least one of them, and then one FILL and
325 XDP_SHARED_UMEM option and provide the initial socket's fd in the
327 socket. These two sockets will now share one and the same UMEM.
330 case where sockets were bound to the same queue id and
337 takes a reference to a FILL ring and a COMPLETION ring that will be
338 created for you and bound to the shared UMEM. You can use this
340 second and following ones and use xsk_socket__create() for the first
344 and device, as well as between queues on the same device and between
351 present in the FILL ring and the TX ring, the rings for which user
360 more buffers on the FILL ring and no buffers left on the RX HW ring of
362 receive any packets (as there are no buffers to put them in), and the
364 FILL ring and then call poll() so that the kernel driver can put these
365 buffers on the HW ring and start to receive packets.
383 better performance especially if you run the application and the
385 application and the kernel driver, as it reduces the number of
392 FILL, and COMPLETION rings respectively should have. It is mandatory
393 to set the size of at least one of the RX and TX rings. If you set
394 both, you will be able to both receive and send traffic from your
396 resources by only setting up one of them. Both the FILL ring and the
399 first one does not have a UMEM and should in that case not have any
405 In libbpf, you can create Rx-only and Tx-only sockets by supplying
406 NULL to the rx and tx arguments, respectively, to the
411 going to receive something when you in fact will not, and this can
419 pointer to the beginning of this area and the size of it. Moreover, it
422 UMEM area that is 128K and a chunk size of 2K, this means that you
424 area and that your largest packet size can be 2K.
437 is created by a privileged process and passed to a non-privileged one.
445 and passed to the driver at one send syscall. It is applied in the copy
447 better throughput and less frequency of send syscall.
474 and transmit packets consisting of multiple buffers both in copy and
476 frames/buffers, one with the header and the other one with the data,
495 XDP_PKT_CONTD is introduced in the options field of the Rx and Tx
497 descriptor and if it is false (0) it means this is the last descriptor
501 and the apps set the options field to zero for Tx, as anything else
508 descriptors/frames of this packet are marked as invalid and not
518 descriptors accumulated so far are dropped and treated as
533 multiple descriptors, if needed, and sets the XDP_PKT_CONTD flag as
537 and it continues with the next buffer in the following
546 packet. It might end in the middle of a packet and the rest of the
551 An example program each for Rx and Tx multi-buffer support can be found
558 application and the XDP program. For a complete setup and usage example,
578 A simple but not so performance ring dequeue and enqueue could look
630 But please use the libbpf functions as they are optimized and ready to
677 simplicity) ignoring that the umem is finite in size, and that we
730 a driver, then AF_XDP will also support that in SKB and DRV mode.
733 mode, use XDP_FEATURES and first check the NETDEV_XDP_ACT_XSK_ZEROCOPY
734 flag. If it is set, it means that at least zero-copy is supported and
735 you should go and check the netlink attribute
753 Zero-copy drivers usually use the batched APIs for Rx and Tx
776 For XDP_SKB mode, use the switch "-S" instead of "-N" and all options
779 This sample application uses libbpf to make the setup and usage of
790 allocates one RX and TX queue pair per core. So on a 8 core system,
793 specify a specific queue id to bind to and it is only the traffic
803 id 0, and then bind to queue 0. You can use ethtool to do this::
810 UDP traffic to and from port 4242 are sent to queue 2::
825 sockets bound to different queue ids, for example X and Y, but only
829 traffic to the correct queue id and socket.
835 same buffer into the FILL ring and the TX ring at the same time, the