examples/l3fwd: add FIB infrastructure
[dpdk.git] / doc / guides / sample_app_ug / ipsec_secgw.rst
index 1f37dcc..2dc39aa 100644 (file)
@@ -125,7 +125,7 @@ The application has a number of command line options::
 
    ./<build_dir>/examples/dpdk-ipsec-secgw [EAL options] --
                         -p PORTMASK -P -u PORTMASK -j FRAMESIZE
-                        -l -w REPLAY_WINOW_SIZE -e -a
+                        -l -w REPLAY_WINDOW_SIZE -e -a
                         -c SAD_CACHE_SIZE
                         -s NUMBER_OF_MBUFS_IN_PACKET_POOL
                         -f CONFIG_FILE_PATH
@@ -161,7 +161,7 @@ Where:
 
 *   ``-l``: enables code-path that uses librte_ipsec.
 
-*   ``-w REPLAY_WINOW_SIZE``: specifies the IPsec sequence number replay window
+*   ``-w REPLAY_WINDOW_SIZE``: specifies the IPsec sequence number replay window
     size for each Security Association (available only with librte_ipsec
     code path).
 
@@ -323,15 +323,15 @@ This means that if the application is using a single core and both hardware
 and software crypto devices are detected, hardware devices will be used.
 
 A way to achieve the case where you want to force the use of virtual crypto
-devices is to whitelist the Ethernet devices needed and therefore implicitly
-blacklisting all hardware crypto devices.
+devices is to only use the Ethernet devices needed (via the allow flag)
+and therefore implicitly blocking all hardware crypto devices.
 
 For example, something like the following command line:
 
 .. code-block:: console
 
     ./<build_dir>/examples/dpdk-ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048 \
-            -w 81:00.0 -w 81:00.1 -w 81:00.2 -w 81:00.3 \
+            -a 81:00.0 -a 81:00.1 -a 81:00.2 -a 81:00.3 \
             --vdev "crypto_aesni_mb" --vdev "crypto_null" \
            -- \
             -p 0xf -P -u 0x3 --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)" \
@@ -500,7 +500,7 @@ The SA rule syntax is shown as follows:
 
     sa <dir> <spi> <cipher_algo> <cipher_key> <auth_algo> <auth_key>
     <mode> <src_ip> <dst_ip> <action_type> <port_id> <fallback>
-    <flow-direction> <port_id> <queue_id>
+    <flow-direction> <port_id> <queue_id> <udp-encap>
 
 where each options means:
 
@@ -709,6 +709,17 @@ where each options means:
    * *port_id*: Port ID of the NIC for which the SA is configured.
    * *queue_id*: Queue ID to which traffic should be redirected.
 
+ ``<udp-encap>``
+
+ * Option to enable IPsec UDP encapsulation for NAT Traversal.
+   Only *lookaside-protocol-offload* mode is supported at the moment.
+
+ * Optional: Yes, it is disabled by default
+
+ * Syntax:
+
+   * *udp-encap*
+
 Example SA rules:
 
 .. code-block:: console
@@ -929,13 +940,13 @@ The user must setup the following environment variables:
 
 *   ``REMOTE_IFACE``: interface name for the test-port on the DUT.
 
-*   ``ETH_DEV``: ethernet device to be used on the SUT by DPDK ('-w <pci-id>')
+*   ``ETH_DEV``: ethernet device to be used on the SUT by DPDK ('-a <pci-id>')
 
 Also the user can optionally setup:
 
 *   ``SGW_LCORE``: lcore to run ipsec-secgw on (default value is 0)
 
-*   ``CRYPTO_DEV``: crypto device to be used ('-w <pci-id>'). If none specified
+*   ``CRYPTO_DEV``: crypto device to be used ('-a <pci-id>'). If none specified
     appropriate vdevs will be created by the script
 
 Scripts can be used for multiple test scenarios. To check all available
@@ -1023,4 +1034,4 @@ Available options:
 *   ``-h`` Show usage.
 
 If <ipsec_mode> is specified, only tests for that mode will be invoked. For the
-list of available modes please refer to run_test.sh.
\ No newline at end of file
+list of available modes please refer to run_test.sh.