ethdev: add namespace
[dpdk.git] / doc / guides / sample_app_ug / ipsec_secgw.rst
index 038f593..782574d 100644 (file)
@@ -93,7 +93,7 @@ Additionally the event mode introduces two submodes of processing packets:
   protocol use case, the worker thread resembles l2fwd worker thread as the IPsec
   processing is done entirely in HW. This mode can be used to benchmark the raw
   performance of the HW. The driver submode is selected with --single-sa option
-  (used also by poll mode). When --single-sa option is used in conjution with event
+  (used also by poll mode). When --single-sa option is used in conjunction with event
   mode then index passed to --single-sa is ignored.
 
 * App submode: This submode has all the features currently implemented with the
@@ -116,12 +116,6 @@ To compile the sample application see :doc:`compiling`.
 
 The application is located in the ``ipsec-secgw`` sub-directory.
 
-#. [Optional] Build the application for debugging:
-   This option adds some extra flags, disables compiler optimizations and
-   is verbose::
-
-       make DEBUG=1
-
 
 Running the Application
 -----------------------
@@ -129,9 +123,9 @@ Running the Application
 The application has a number of command line options::
 
 
-   ./build/ipsec-secgw [EAL 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
@@ -167,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).
 
@@ -215,12 +209,12 @@ Where:
     device will ensure the ordering. Ordering will be lost when tried in PARALLEL.
 
 *   ``--rxoffload MASK``: RX HW offload capabilities to enable/use on this port
-    (bitmask of DEV_RX_OFFLOAD_* values). It is an optional parameter and
+    (bitmask of RTE_ETH_RX_OFFLOAD_* values). It is an optional parameter and
     allows user to disable some of the RX HW offload capabilities.
     By default all HW RX offloads are enabled.
 
 *   ``--txoffload MASK``: TX HW offload capabilities to enable/use on this port
-    (bitmask of DEV_TX_OFFLOAD_* values). It is an optional parameter and
+    (bitmask of RTE_ETH_TX_OFFLOAD_* values). It is an optional parameter and
     allows user to disable some of the TX HW offload capabilities.
     By default all HW TX offloads are enabled.
 
@@ -245,7 +239,7 @@ The mapping of lcores to port/queues is similar to other l3fwd applications.
 
 For example, given the following command line to run application in poll mode::
 
-    ./build/ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048       \
+    ./<build_dir>/examples/dpdk-ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048       \
            --vdev "crypto_null" -- -p 0xf -P -u 0x3             \
            --config="(0,0,20),(1,0,20),(2,0,21),(3,0,21)"       \
            -f /path/to/config_file --transfer-mode poll         \
@@ -297,7 +291,7 @@ where each option means:
 Similarly for example, given the following command line to run application in
 event app mode::
 
-    ./build/ipsec-secgw -c 0x3 -- -P -p 0x3 -u 0x1       \
+    ./<build_dir>/examples/dpdk-ipsec-secgw -c 0x3 -- -P -p 0x3 -u 0x1       \
            -f /path/to/config_file --transfer-mode event \
            --event-schedule-type parallel                \
 
@@ -329,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/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 \
+    ./<build_dir>/examples/dpdk-ipsec-secgw -l 20,21 -n 4 --socket-mem 0,2048 \
+            -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)" \
@@ -348,7 +342,7 @@ Configurations
 --------------
 
 The following sections provide the syntax of configurations to initialize
-your SP, SA, Routing and Neighbour tables.
+your SP, SA, Routing, Flow and Neighbour tables.
 Configurations shall be specified in the configuration file to be passed to
 the application. The file is then parsed by the application. The successful
 parsing will result in the appropriate rules being applied to the tables
@@ -369,7 +363,7 @@ General rule syntax
 
 The parse treats one line in the configuration file as one configuration
 item (unless the line concatenation symbol exists). Every configuration
-item shall follow the syntax of either SP, SA, Routing or Neighbour
+item shall follow the syntax of either SP, SA, Routing, Flow or Neighbour
 rules specified below.
 
 The configuration parser supports the following special symbols:
@@ -506,6 +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> <udp-encap>
 
 where each options means:
 
@@ -538,6 +533,7 @@ where each options means:
 
    * *null*: NULL algorithm
    * *aes-128-cbc*: AES-CBC 128-bit algorithm
+   * *aes-192-cbc*: AES-CBC 192-bit algorithm
    * *aes-256-cbc*: AES-CBC 256-bit algorithm
    * *aes-128-ctr*: AES-CTR 128-bit algorithm
    * *3des-cbc*: 3DES-CBC 192-bit algorithm
@@ -593,6 +589,8 @@ where each options means:
  * Available options:
 
    * *aes-128-gcm*: AES-GCM 128-bit algorithm
+   * *aes-192-gcm*: AES-GCM 192-bit algorithm
+   * *aes-256-gcm*: AES-GCM 256-bit algorithm
 
  * Syntax: *cipher_algo <your algorithm>*
 
@@ -604,11 +602,12 @@ where each options means:
    Must be followed by <aead_algo> option
 
  * Syntax: Hexadecimal bytes (0x0-0xFF) concatenate by colon symbol ':'.
-   The number of bytes should be as same as the specified AEAD algorithm
-   key size.
+   Last 4 bytes of the provided key will be used as 'salt' and so, the
+   number of bytes should be same as the sum of specified AEAD algorithm
+   key size and salt size (4 bytes).
 
    For example: *aead_key A1:B2:C3:D4:A1:B2:C3:D4:A1:B2:C3:D4:
-   A1:B2:C3:D4*
+   A1:B2:C3:D4:A1:B2:C3:D4*
 
 ``<mode>``
 
@@ -698,6 +697,29 @@ where each options means:
 
    * *fallback lookaside-none*
 
+``<flow-direction>``
+
+ * Option for redirecting a specific inbound ipsec flow of a port to a specific
+   queue of that port.
+
+ * Optional: Yes.
+
+ * Available options:
+
+   * *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
@@ -727,6 +749,9 @@ Example SA rules:
     mode ipv4-tunnel src 172.16.2.5 dst 172.16.1.5 \
     type inline-crypto-offload port_id 0
 
+    sa in 117 cipher_algo null auth_algo null mode ipv4-tunnel src 172.16.2.7 \
+    dst 172.16.1.7 flow-direction 0 2
+
 Routing rule syntax
 ^^^^^^^^^^^^^^^^^^^
 
@@ -788,6 +813,80 @@ Example SP rules:
 
     rt ipv6 dst 1111:1111:1111:1111:1111:1111:1111:5555/116 port 0
 
+Flow rule syntax
+^^^^^^^^^^^^^^^^
+
+Flow rule enables the usage of hardware classification capabilities to match specific
+ingress traffic and redirect the packets to the specified queue. This feature is
+optional and relies on hardware ``rte_flow`` support.
+
+The flow rule syntax is shown as follows:
+
+.. code-block:: console
+
+    flow <ip_ver> <src_ip> <dst_ip> <port> <queue>
+
+
+where each options means:
+
+``<ip_ver>``
+
+ * IP protocol version
+
+ * Optional: No
+
+ * Available options:
+
+   * *ipv4*: IP protocol version 4
+   * *ipv6*: IP protocol version 6
+
+``<src_ip>``
+
+ * The source IP address and mask
+
+ * Optional: Yes, default address 0.0.0.0 and mask of 0 will be used
+
+ * Syntax:
+
+   * *src X.X.X.X/Y* for IPv4
+   * *src XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX/Y* for IPv6
+
+``<dst_ip>``
+
+ * The destination IP address and mask
+
+ * Optional: Yes, default address 0.0.0.0 and mask of 0 will be used
+
+ * Syntax:
+
+   * *dst X.X.X.X/Y* for IPv4
+   * *dst XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX/Y* for IPv6
+
+``<port>``
+
+ * The traffic input port id
+
+ * Optional: yes, default input port 0 will be used
+
+ * Syntax: *port X*
+
+``<queue>``
+
+ * The traffic input queue id
+
+ * Optional: yes, default input queue 0 will be used
+
+ * Syntax: *queue X*
+
+Example flow rules:
+
+.. code-block:: console
+
+    flow ipv4 dst 172.16.1.5/32 port 0 queue 0
+
+    flow ipv6 dst 1111:1111:1111:1111:1111:1111:1111:5555/116 port 1 queue 0
+
+
 Neighbour rule syntax
 ^^^^^^^^^^^^^^^^^^^^^
 
@@ -841,19 +940,21 @@ 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
 
-*   ``MULTI_SEG_TEST``: ipsec-secgw option to enable reassembly support and
-    specify size of reassembly table (e.g.
-    ``MULTI_SEG_TEST='--reassemble 128'``). This option must be set for
-    fallback session tests.
+Scripts can be used for multiple test scenarios. To check all available
+options run:
+
+.. code-block:: console
+
+    /bin/bash run_test.sh -h
 
 Note that most of the tests require the appropriate crypto PMD/device to be
 available.
@@ -897,17 +998,40 @@ SUT OS(TAP)--(plain)-->(TAP)psec-secgw(NIC1)--(IPsec)-->(NIC1)DUT OS
 
 It then tries to perform some data transfer using the scheme described above.
 
-usage
+Usage
 ~~~~~
 
-In the ipsec-secgw/test directory
+In the ipsec-secgw/test directory run
+
+/bin/bash run_test.sh <options> <ipsec_mode>
+
+Available options:
+
+*   ``-4`` Perform tests with use of IPv4. One or both [-46] options needs to be
+    selected.
+
+*   ``-6`` Perform tests with use of IPv6. One or both [-46] options needs to be
+    selected.
+
+*   ``-m`` Add IPSec tunnel mixed IP version tests - outer IP version different
+    than inner. Inner IP version will match selected option [-46].
+
+*   ``-i`` Run tests in inline mode. Regular tests will not be invoked.
+
+*   ``-f`` Run tests for fallback mechanism. Regular tests will not be invoked.
+
+*   ``-l`` Run tests in legacy mode only. It cannot be used with options [-fsc].
+    On default library mode is used.
 
-to run one test for IPv4 or IPv6
+*   ``-s`` Run all tests with reassembly support. On default only tests for
+    fallback mechanism use reassembly support.
 
-/bin/bash linux_test(4|6).sh <ipsec_mode>
+*   ``-c`` Run tests with use of cpu-crypto. For inline tests it will not be
+    applied. On default lookaside-none is used.
 
-to run all tests for IPv4 or IPv6
+*   ``-p`` Perform packet validation tests. Option [-46] is not required.
 
-/bin/bash run_test.sh -4|-6
+*   ``-h`` Show usage.
 
-For the list of available modes please refer to run_test.sh.
+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.