CSIT-612 Report: Minimization of hand-crafted content.

[csit.git] / docs / report / vpp_performance_tests / overview.rst

diff --git a/docs/report/vpp_performance_tests/overview.rst b/docs/report/vpp_performance_tests/overview.rst
index dbc1612..ccf8063 100644 (file)
--- a/docs/report/vpp_performance_tests/overview.rst
+++ b/docs/report/vpp_performance_tests/overview.rst
@@ -147,6 +147,8 @@ CSIT |release| includes following performance test suites, listed per NIC type:
   - **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
 
@@ -192,7 +194,7 @@ Performance Tests Naming
 ------------------------
 
 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
@@ -311,8 +313,8 @@ Methodology: KVM VM vhost
 -------------------------
 
 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:
@@ -327,3 +329,62 @@ of VPP+VM system less sensitive to other Linux OS system tasks by reducing
 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.