Skip to content

Commit 03e38d3

Browse files
magnus-karlssonborkmann
authored andcommitted
Revert "xsk: Document ability to redirect to any socket bound to the same umem"
This reverts commit 968595a. Reported-by: Yuval El-Hanany <[email protected]> Signed-off-by: Magnus Karlsson <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/xdp-newbies/[email protected] Link: https://lore.kernel.org/bpf/[email protected]
1 parent 7fcf26b commit 03e38d3

File tree

1 file changed

+14
-19
lines changed

1 file changed

+14
-19
lines changed

Documentation/networking/af_xdp.rst

Lines changed: 14 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -329,24 +329,23 @@ XDP_SHARED_UMEM option and provide the initial socket's fd in the
329329
sxdp_shared_umem_fd field as you registered the UMEM on that
330330
socket. These two sockets will now share one and the same UMEM.
331331

332-
In this case, it is possible to use the NIC's packet steering
333-
capabilities to steer the packets to the right queue. This is not
334-
possible in the previous example as there is only one queue shared
335-
among sockets, so the NIC cannot do this steering as it can only steer
336-
between queues.
337-
338-
In libxdp (or libbpf prior to version 1.0), you need to use the
339-
xsk_socket__create_shared() API as it takes a reference to a FILL ring
340-
and a COMPLETION ring that will be created for you and bound to the
341-
shared UMEM. You can use this function for all the sockets you create,
342-
or you can use it for the second and following ones and use
343-
xsk_socket__create() for the first one. Both methods yield the same
344-
result.
332+
There is no need to supply an XDP program like the one in the previous
333+
case where sockets were bound to the same queue id and
334+
device. Instead, use the NIC's packet steering capabilities to steer
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
337+
can only steer between queues.
338+
339+
In libbpf, you need to use the xsk_socket__create_shared() API as it
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
342+
function for all the sockets you create, or you can use it for the
343+
second and following ones and use xsk_socket__create() for the first
344+
one. Both methods yield the same result.
345345

346346
Note that a UMEM can be shared between sockets on the same queue id
347347
and device, as well as between queues on the same device and between
348-
devices at the same time. It is also possible to redirect to any
349-
socket as long as it is bound to the same umem with XDP_SHARED_UMEM.
348+
devices at the same time.
350349

351350
XDP_USE_NEED_WAKEUP bind flag
352351
-----------------------------
@@ -823,10 +822,6 @@ A: The short answer is no, that is not supported at the moment. The
823822
switch, or other distribution mechanism, in your NIC to direct
824823
traffic to the correct queue id and socket.
825824

826-
Note that if you are using the XDP_SHARED_UMEM option, it is
827-
possible to switch traffic between any socket bound to the same
828-
umem.
829-
830825
Q: My packets are sometimes corrupted. What is wrong?
831826

832827
A: Care has to be taken not to feed the same buffer in the UMEM into

0 commit comments

Comments
 (0)