- **VXLAN** - VXLAN overlay tunnelling integration with L2XC and L2BD.
- **QoS Policer** - ingress packet rate measuring, marking and limiting
(IPv4).
+ - **CGNAT** - Carrier Grade Network Address Translation tests with varying
+ number of users and ports per user.
- 2port40GE XL710 Intel
------------------------
CSIT |release| follows a common structured naming convention for all
-performance and system functional tests, introduced in CSIT rls1701.
+performance and system functional tests, introduced in CSIT |release-1|.
The naming should be intuitive for majority of the tests. Complete
description of CSIT test naming convention is provided on `CSIT test naming wiki
-------------------------
CSIT |release| introduced environment configuration changes to KVM Qemu vhost-
-user tests in order to more representatively measure VPP-17.04 performance in
-configurations with vhost-user interfaces and VMs.
+user tests in order to more representatively measure |vpp-release| performance
+in configurations with vhost-user interfaces and VMs.
Current setup of CSIT FD.io performance lab is using tuned settings for more
optimal performance of KVM Qemu:
their interference on CPU cores that are designated for critical software
tasks under test, namely VPP worker threads in host and Testpmd threads in
guest dealing with data plan.
+
+Methodology: IPSec with Intel QAT HW cards
+------------------------------------------
+
+VPP IPSec performance tests are using DPDK cryptodev device driver in
+combination with HW cryptodev devices - Intel QAT 8950 50G - present in
+LF FD.io physical testbeds. DPDK cryptodev can be used for all IPSec
+data plane functions supported by VPP.
+
+Currently CSIT |release| implements following IPSec test cases:
+
+- AES-GCM, CBC-SHA1 ciphers, in combination with IPv4 routed-forwarding
+ with Intel xl710 NIC.
+- CBC-SHA1 ciphers, in combination with LISP-GPE overlay tunneling for
+ IPv4-over-IPv4 with Intel xl710 NIC.
+
+Methodology: TRex Traffic Generator Usage
+-----------------------------------------
+
+The `TRex traffic generator <https://wiki.fd.io/view/TRex>`_ is used for all
+CSIT performance tests. TRex stateless mode is used to measure NDR and PDR
+throughputs using binary search (NDR and PDR discovery tests) and for quick
+checks of DUT performance against the reference NDRs (NDR check tests) for
+specific configuration.
+
+TRex is installed and run on the TG compute node. The typical procedure is:
+
+ - If the TRex is not already installed on TG, it is installed in the
+ suite setup phase - see `TRex intallation`_.
+ - TRex configuration is set in its configuration file
+ ::
+
+ /etc/trex_cfg.yaml
+
+ - TRex is started in the background mode
+ ::
+
+ sh -c 'cd /opt/trex-core-2.25/scripts/ && sudo nohup ./t-rex-64 -i -c 7 --iom 0 > /dev/null 2>&1 &' > /dev/null
+
+ - There are traffic streams dynamically prepared for each test. The traffic
+ is sent and the statistics obtained using trex_stl_lib.api.STLClient.
+
+**Measuring packet loss**
+
+ - Create an instance of STLClient
+ - Connect to the client
+ - Add all streams
+ - Clear statistics
+ - Send the traffic for defined time
+ - Get the statistics
+
+If there is a warm-up phase required, the traffic is sent also before test and
+the statistics are ignored.
+
+**Measuring latency**
+
+If measurement of latency is requested, two more packet streams are created (one
+for each direction) with TRex flow_stats parameter set to STLFlowLatencyStats. In
+that case, returned statistics will also include min/avg/max latency values.