threads and supports inline protocol only.** It also provides infrastructure for
non-internal port however does not define any worker threads.
+ Event mode also supports event vectorization. The event devices, ethernet device
+ pairs which support the capability ``RTE_EVENT_ETH_RX_ADAPTER_CAP_EVENT_VECTOR`` can
+ aggregate packets based on flow characteristics and generate a ``rte_event``
+ containing ``rte_event_vector``.
+ The aggregation size and timeout can be given using command line options vector-size
+ (default vector-size is 16) and vector-tmo (default vector-tmo is 102400ns).
+ By default event vectorization is disabled and it can be enabled using event-vector
+ option.
+
Additionally the event mode introduces two submodes of processing packets:
* Driver submode: This submode has bare minimum changes in the application to support
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
* No IPv6 options headers.
* No AH mode.
-* Supported algorithms: AES-CBC, AES-CTR, AES-GCM, 3DES-CBC, HMAC-SHA1 and NULL.
+* Supported algorithms: AES-CBC, AES-CTR, AES-GCM, 3DES-CBC, HMAC-SHA1,
+ AES-GMAC, AES_CTR, AES_XCBC_MAC, AES_CCM, CHACHA20_POLY1305 and NULL.
* Each SA must be handle by a unique lcore (*1 RX queue per port*).
Compiling the Application
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
-----------------------
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
+ -t STATISTICS_INTERVAL
-s NUMBER_OF_MBUFS_IN_PACKET_POOL
-f CONFIG_FILE_PATH
--config (port,queue,lcore)[,(port,queue,lcore)]
* ``-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).
Zero value disables cache.
Default value: 128.
+* ``-t``: specifies the statistics screen update interval in seconds. If set
+ to zero or omitted statistics screen is disabled.
+ Default value: 0.
+
* ``-s``: sets number of mbufs in packet pool, if not provided number of mbufs
will be calculated based on number of cores, eth ports and crypto queues.
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.
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 \
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 \
+ --event-schedule-type parallel --event-vector --vector-size 32 \
+ --vector-tmo 102400 \
where each option means:
* The ``--event-schedule-type`` option selects parallel ordering of event queues.
+* The ``--event-vector`` option enables event vectorization.
+
+* The ``--vector-size`` option specifies max vector size.
+
+* The ``--vector-tmo`` option specifies max timeout in nanoseconds for vectorization.
+
Refer to the *DPDK Getting Started Guide* for general information on running
applications and the Environment Abstraction Layer (EAL) options.
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)" \
--------------
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
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:
* *protect <SA_idx>*: the specified traffic is protected by SA rule
with id SA_idx
- * *bypass*: the specified traffic traffic is bypassed
+ * *bypass*: the specified traffic is bypassed
* *discard*: the specified traffic is discarded
``<priority>``
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:
* *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* and *inline-crypto-offload* modes are
+ supported at the moment.
+
+ * Optional: Yes, it is disabled by default
+
+ * Syntax:
+
+ * *udp-encap*
+
+ ``<mss>``
+
+ * Maximum segment size for TSO offload, available for egress SAs only.
+
+ * Optional: Yes, TSO offload not set by default
+
+ * Syntax:
+
+ * *mss N* N is the segment size in bytes
+
+
+``<telemetry>``
+
+ * Option to enable per SA telemetry.
+ Currently only supported with IPsec library path.
+
+ * Optional: Yes, it is disabled by default
+
+ * Syntax:
+
+ * *telemetry*
+
+ ``<esn>``
+
+ * Enable ESN and set the initial ESN value.
+
+ * Optional: Yes, ESN not enabled by default
+
+ * Syntax:
+
+ * *esn N* N is the initial ESN value
+
Example SA rules:
.. code-block:: console
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
^^^^^^^^^^^^^^^^^^^^^
* ``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
* ``-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.
git.droids-corp.org / dpdk.git / blobdiff