[PATCH] af_xdp: use standard hierarchy for FAQs

[PATCH] af_xdp: use standard hierarchy for FAQs

[nick black]

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@linux.com>
---
 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