+CSIT |release| introduced test environment configuration changes to KVM Qemu
+vhost-user tests in order to more representatively measure |vpp-release|
+performance in configurations with vhost-user interfaces and different Qemu
+settings.
+
+FD.io CSIT performance lab is testing VPP vhost with KVM VMs using following
+environment settings:
+
+- Tests with varying Qemu virtio queue (a.k.a. vring) sizes: [vr256] default 256
+ descriptors, [vr1024] 1024 descriptors to optimize for packet throughput;
+
+- Tests with varying Linux :abbr:`CFS (Completely Fair Scheduler)` settings:
+ [cfs] default settings, [cfsrr1] CFS RoundRobin(1) policy applied to all data
+ plane threads handling test packet path including all VPP worker threads and
+ all Qemu testpmd poll-mode threads;
+
+- Resulting test cases are all combinations with [vr256,vr1024] and
+ [cfs,cfsrr1] settings;
+
+- Adjusted Linux kernel :abbr:`CFS (Completely Fair Scheduler)` scheduler policy
+ for data plane threads used in CSIT is documented in
+ `CSIT Performance Environment Tuning wiki <https://wiki.fd.io/view/CSIT/csit-perf-env-tuning-ubuntu1604>`_.
+ The purpose is to verify performance impact (NDR, PDR throughput) and
+ same test measurements repeatability, by making VPP and VM data plane
+ threads less susceptible to other Linux OS system tasks hijacking CPU
+ cores running those data plane threads.
+
+Methodology: LXC and Docker Containers memif
+--------------------------------------------
+
+CSIT |release| introduced additional tests taking advantage of VPP memif
+virtual interface (shared memory interface) tests to interconnect VPP
+instances. VPP vswitch instance runs in bare-metal user-mode handling
+Intel x520 NIC 10GbE interfaces and connecting over memif (Master side)
+virtual interfaces to more instances of VPP running in :abbr:`LXC (Linux
+Container)` or in Docker Containers, both with memif virtual interfaces
+(Slave side). LXCs and Docker Containers run in a priviliged mode with
+VPP data plane worker threads pinned to dedicated physical CPU cores per
+usual CSIT practice. All VPP instances run the same version of software.
+This test topology is equivalent to existing tests with vhost-user and
+VMs as described earlier in :ref:`tested_physical_topologies`.
+
+More information about CSIT LXC and Docker Container setup and control
+is available in :ref:`container_orchestration_in_csit`.
+
+Methodology: Container Topologies Orchestrated by K8s
+-----------------------------------------------------
+
+CSIT |release| introduced new tests of Container topologies connected
+over the memif virtual interface (shared memory interface). In order to
+provide simple topology coding flexibility and extensibility container
+orchestration is done with `Kubernetes <https://github.com/kubernetes>`_
+using `Docker <https://github.com/docker>`_ images for all container
+applications including VPP. `Ligato <https://github.com/ligato>`_ is
+used to address the container networking orchestration that is
+integrated with K8s, including memif support.
+
+For these tests VPP vswitch instance runs in a Docker Container handling
+Intel x520 NIC 10GbE interfaces and connecting over memif (Master side)
+virtual interfaces to more instances of VPP running in Docker Containers
+with memif virtual interfaces (Slave side). All Docker Containers run in
+a priviliged mode with VPP data plane worker threads pinned to dedicated
+physical CPU cores per usual CSIT practice. All VPP instances run the
+same version of software. This test topology is equivalent to existing
+tests with vhost-user and VMs as described earlier in
+:ref:`tested_physical_topologies`.
+
+More information about CSIT Container Topologies Orchestrated by K8s is
+available in :ref:`container_orchestration_in_csit`.
+
+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
+-----------------------------------------
+
+`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 <t-rex-install-dir>/scripts/ && sudo nohup ./t-rex-64 -i -c 7 --iom 0 > /tmp/trex.log 2>&1 &' > /dev/null
+
+- There are traffic streams dynamically prepared for each test, based on traffic
+ profiles. The traffic is sent and the statistics obtained using
+ :command:`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.
+
+Methodology: TCP/IP tests with WRK tool
+---------------------------------------
+
+`WRK HTTP benchmarking tool <https://github.com/wg/wrk>`_ is used for
+experimental TCP/IP and HTTP tests of VPP TCP/IP stack and built-in
+static HTTP server. WRK has been chosen as it is capable of generating
+significant TCP/IP and HTTP loads by scaling number of threads across
+multi-core processors.
+
+This in turn enables quite high scale benchmarking of the main TCP/IP
+and HTTP service including HTTP TCP/IP Connections-Per-Second (CPS),
+HTTP Requests-Per-Second and HTTP Bandwidth Throughput.
+
+The initial tests are designed as follows:
+
+- HTTP and TCP/IP Connections-Per-Second (CPS)
+
+ - WRK configured to use 8 threads across 8 cores, 1 thread per core.
+ - Maximum of 50 concurrent connections across all WRK threads.
+ - Timeout for server responses set to 5 seconds.
+ - Test duration is 30 seconds.
+ - Expected HTTP test sequence:
+
+ - Single HTTP GET Request sent per open connection.
+ - Connection close after valid HTTP reply.
+ - Resulting flow sequence - 8 packets: >S,<S-A,>A,>Req,<Rep,>F,<F,> A.