af_xdp: use standard hierarchy for FAQs The formatting of the AF_XDP FAQ section led to nasty HTML. Adopt the scheme used in netdev-FAQ.rst, which exploits the standard rst hierarchy. Signed-off-by: nick black <nickblack@xxxxxxxxx> --- Documentation/networking/af_xdp.rst | 110 ++++++++++++++-------------- 1 file changed, 56 insertions(+), 54 deletions(-) diff --git Documentation/networking/af_xdp.rst Documentation/networking/af_xdp.rst index 60b217b436be..f049d7d61c04 100644 --- Documentation/networking/af_xdp.rst +++ Documentation/networking/af_xdp.rst @@ -560,60 +560,62 @@ code in tools/lib/bpf/xsk.[ch]. FAQ ======= -Q: I am not seeing any traffic on the socket. What am I doing wrong? - -A: When a netdev of a physical NIC is initialized, Linux usually - allocates one RX and TX queue pair per core. So on a 8 core system, - queue ids 0 to 7 will be allocated, one per core. In the AF_XDP - bind call or the xsk_socket__create libbpf function call, you - specify a specific queue id to bind to and it is only the traffic - towards that queue you are going to get on you socket. So in the - example above, if you bind to queue 0, you are NOT going to get any - traffic that is distributed to queues 1 through 7. If you are - lucky, you will see the traffic, but usually it will end up on one - of the queues you have not bound to. - - There are a number of ways to solve the problem of getting the - traffic you want to the queue id you bound to. If you want to see - all the traffic, you can force the netdev to only have 1 queue, queue - id 0, and then bind to queue 0. You can use ethtool to do this:: - - sudo ethtool -L <interface> combined 1 - - If you want to only see part of the traffic, you can program the - NIC through ethtool to filter out your traffic to a single queue id - that you can bind your XDP socket to. Here is one example in which - UDP traffic to and from port 4242 are sent to queue 2:: - - sudo ethtool -N <interface> rx-flow-hash udp4 fn - sudo ethtool -N <interface> flow-type udp4 src-port 4242 dst-port \ - 4242 action 2 - - A number of other ways are possible all up to the capabilities of - the NIC you have. - -Q: Can I use the XSKMAP to implement a switch betwen different umems - in copy mode? - -A: The short answer is no, that is not supported at the moment. The - XSKMAP can only be used to switch traffic coming in on queue id X - to sockets bound to the same queue id X. The XSKMAP can contain - sockets bound to different queue ids, for example X and Y, but only - traffic goming in from queue id Y can be directed to sockets bound - to the same queue id Y. In zero-copy mode, you should use the - switch, or other distribution mechanism, in your NIC to direct - traffic to the correct queue id and socket. - -Q: My packets are sometimes corrupted. What is wrong? - -A: Care has to be taken not to feed the same buffer in the UMEM into - more than one ring at the same time. If you for example feed the - same buffer into the FILL ring and the TX ring at the same time, the - NIC might receive data into the buffer at the same time it is - sending it. This will cause some packets to become corrupted. Same - thing goes for feeding the same buffer into the FILL rings - belonging to different queue ids or netdevs bound with the - XDP_SHARED_UMEM flag. +I am not seeing any traffic on the socket. What am I doing wrong? +----------------------------------------------------------------- + +When a netdev of a physical NIC is initialized, Linux usually +allocates one RX and TX queue pair per core. So on a 8 core system, +queue ids 0 to 7 will be allocated, one per core. In the AF_XDP +bind call or the xsk_socket__create libbpf function call, you +specify a specific queue id to bind to and it is only the traffic +towards that queue you are going to get on you socket. So in the +example above, if you bind to queue 0, you are NOT going to get any +traffic that is distributed to queues 1 through 7. If you are +lucky, you will see the traffic, but usually it will end up on one +of the queues you have not bound to. + +There are a number of ways to solve the problem of getting the +traffic you want to the queue id you bound to. If you want to see +all the traffic, you can force the netdev to only have 1 queue, queue +id 0, and then bind to queue 0. You can use ethtool to do this:: + + sudo ethtool -L <interface> combined 1 + +If you want to only see part of the traffic, you can program the +NIC through ethtool to filter out your traffic to a single queue id +that you can bind your XDP socket to. Here is one example in which +UDP traffic to and from port 4242 are sent to queue 2:: + + sudo ethtool -N <interface> rx-flow-hash udp4 fn + sudo ethtool -N <interface> flow-type udp4 src-port 4242 dst-port \ + 4242 action 2 + +A number of other ways are possible all up to the capabilities of +the NIC you have. + +Can I use the XSKMAP to implement a switch betwen different umems in copy mode? +------------------------------------------------------------------------------- + +The short answer is no, that is not supported at the moment. The +XSKMAP can only be used to switch traffic coming in on queue id X +to sockets bound to the same queue id X. The XSKMAP can contain +sockets bound to different queue ids, for example X and Y, but only +traffic goming in from queue id Y can be directed to sockets bound +to the same queue id Y. In zero-copy mode, you should use the +switch, or other distribution mechanism, in your NIC to direct +traffic to the correct queue id and socket. + +My packets are sometimes corrupted. What is wrong? +-------------------------------------------------- + +Care has to be taken not to feed the same buffer in the UMEM into +more than one ring at the same time. If you for example feed the +same buffer into the FILL ring and the TX ring at the same time, the +NIC might receive data into the buffer at the same time it is +sending it. This will cause some packets to become corrupted. Same +thing goes for feeding the same buffer into the FILL rings +belonging to different queue ids or netdevs bound with the +XDP_SHARED_UMEM flag. Credits ======= -- 2.35.1
