mbuf: remove control mbuf

[dpdk.git] / doc / guides / nics / tap.rst

diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 4986e47..04086b1 100644 (file)
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -46,7 +46,7 @@ These TAP interfaces can be used with Wireshark or tcpdump or Pktgen-DPDK
 along with being able to be used as a network connection to the DPDK
 application. The method enable one or more interfaces is to use the
 ``--vdev=net_tap0`` option on the DPDK application command line. Each
-``--vdev=net_tap1`` option give will create an interface named dtap0, dtap1,
+``--vdev=net_tap1`` option given will create an interface named dtap0, dtap1,
 and so on.
 
 The interface name can be changed by adding the ``iface=foo0``, for example::
@@ -58,6 +58,33 @@ needed, but the interface does not enforce that speed, for example::
 
    --vdev=net_tap0,iface=foo0,speed=25000
 
+Normally the PMD will generate a random MAC address, but when testing or with
+a static configuration the developer may need a fixed MAC address style.
+Using the option ``mac=fixed`` you can create a fixed known MAC address::
+
+   --vdev=net_tap0,mac=fixed
+
+The MAC address will have a fixed value with the last octet incrementing by one
+for each interface string containing ``mac=fixed``. The MAC address is formatted
+as 00:'d':'t':'a':'p':[00-FF]. Convert the characters to hex and you get the
+actual MAC address: ``00:64:74:61:70:[00-FF]``.
+
+It is possible to specify a remote netdevice to capture packets from by adding
+``remote=foo1``, for example::
+
+   --vdev=net_tap,iface=tap0,remote=foo1
+
+If a ``remote`` is set, the tap MAC address will be set to match the remote one
+just after netdevice creation. Using TC rules, traffic from the remote netdevice
+will be redirected to the tap. If the tap is in promiscuous mode, then all
+packets will be redirected. In allmulti mode, all multicast packets will be
+redirected.
+
+Using the remote feature is especially useful for capturing traffic from a
+netdevice that has no support in the DPDK. It is possible to add explicit
+rte_flow rules on the tap PMD to capture specific traffic (see next section for
+examples).
+
 After the DPDK application is started you can send and receive packets on the
 interface using the standard rx_burst/tx_burst APIs in DPDK. From the host
 point of view you can use any host tool like tcpdump, Wireshark, ping, Pktgen
@@ -86,7 +113,14 @@ Flow API support
 ----------------
 
 The tap PMD supports major flow API pattern items and actions, when running on
-linux kernels above 4.2 ("Flower" classifier required). Supported items:
+linux kernels above 4.2 ("Flower" classifier required).
+The kernel support can be checked with this command::
+
+   zcat /proc/config.gz | ( grep 'CLS_FLOWER=' || echo 'not supported' ) |
+   tee -a /dev/stderr | grep -q '=m' &&
+   lsmod | ( grep cls_flower || echo 'try modprobe cls_flower' )
+
+Supported items:
 
 - eth: src and dst (with variable masks), and eth_type (0xffff mask).
 - vlan: vid, pcp, tpid, but not eid. (requires kernel 4.9)