docs/testing/user/userguide/readme.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. SPDX-License-Identifier: CC-BY-4.0
   3 .. (c) Cisco Systems, Inc
   4
   5 Features
   6 ********
   7
   8 Data Plane Performance Measurement Features
   9 -------------------------------------------
  10
  11 NFVbench supports the following main measurement capabilities:
  12
  13 - supports 2 measurement modes:
  14     - *fixed rate* mode to generate traffic at a fixed rate for a fixed duration
  15     - NDR (No Drop Rate) and PDR (Partial Drop Rate) measurement mode
  16 - configurable frame sizes (any list of fixed sizes or 'IMIX')
  17 - built-in packet paths (PVP, PVVP)
  18 - built-in loopback VNFs based on fast L2 or L3 forwarders running in VMs
  19 - configurable number of flows and service chains
  20 - configurable traffic direction (single or bi-directional)
  21 - can support optional VLAN tagging (dot1q) or VxLAN overlays
  22
  23
  24 NDR is the highest throughput achieved without dropping packets.
  25 PDR is the highest throughput achieved without dropping more than a pre-set limit (called PDR threshold or allowance, expressed in %).
  26
  27 Results of each run include the following data:
  28
  29 - Aggregated achieved throughput in bps
  30 - Aggregated achieved packet rate in pps (or fps)
  31 - Actual drop rate in %
  32 - Latency in usec (min, max, average in the current version)
  33
  34 Built-in OpenStack support (optional)
  35 -------------------------------------
  36 NFVbench can optionally stage OpenStack resources to build 1 or more service chains using direct OpenStack APIs. Each service chain is composed of:
  37
  38 - 1 or 2 loopback VM instances per service chain
  39 - 2 Neutron networks per loopback VM
  40
  41 OpenStack resources are staged before traffic is measured using OpenStack APIs (Nova and Neutron) then disposed after completion of measurements.
  42
  43 The loopback VM flavor to use can be configured in the NFVbench configuration file.
  44
  45 Note that NFVbench does not use OpenStack Heat nor any higher level service (VNFM or NFVO) to create the service chains because its
  46 main purpose is to measure the performance of the NFVi infrastructure which is mainly focused on L2 forwarding performance.
  47
  48 External Chains
  49 ---------------
  50 NFVbench supports settings that involve externally staged packet paths with or without OpenStack:
  51
  52 - run benchmarks on existing service chains at the L3 level that are staged externally by any other tool (e.g. any VNF capable of L3 routing)
  53 - run benchmarks on existing L2 chains that are configured externally (e.g. pure L2 forwarder such as DPDK testpmd)
  54
  55 Direct L2 Loopback (Switch or wire loopback)
  56 --------------------------------------------
  57 NFVbench supports benchmarking of pure L2 loopbacks (see "--l2-loopback vlan" option)
  58
  59 - Switch level loopback
  60 - Port to port wire loopback
  61
  62 In this mode, NFVbench will take a vlan ID and send packets from each port to the other port
  63 (dest MAC set to the other port MAC) using the same VLAN ID on both ports.
  64 This can be useful for example to verify that the connectivity to the switch is working properly.
  65
  66 Traffic Generation
  67 ------------------
  68
  69 NFVbench currently integrates with the open source TRex traffic generator:
  70
  71 - `TRex <https://trex-tgn.cisco.com>`_ (pre-built into the NFVbench container)
  72
  73
  74 Supported Packet Paths
  75 ----------------------
  76 Packet paths describe where packets are flowing in the NFVi platform. The most commonly used paths are identified by 3 or 4 letter abbreviations.
  77 A packet path can generally describe the flow of packets associated to one or more service chains, with each service chain composed of 1 or more VNFs.
  78
  79 The following packet paths are currently supported by NFVbench:
  80
  81 - PVP (Physical interface to VM to Physical interface)
  82 - PVVP (Physical interface to VM to VM to Physical interface)
  83 - N*PVP (N concurrent PVP packet paths)
  84 - N*PVVP (N concurrent PVVP packet paths)
  85
  86 The traffic is made of 1 or more flows of L3 frames (UDP packets) with different payload sizes. Each flow is identified by a unique source and destination MAC/IP tuple.
  87
  88
  89 Loopback VM
  90 ^^^^^^^^^^^
  91
  92 NFVbench provides a loopback VM image that runs CentOS with 2 pre-installed forwarders:
  93
  94 - DPDK testpmd configured to do L2 cross connect between 2 virtual interfaces
  95 - FD.io VPP configured to perform L3 routing between 2 virtual interfaces
  96
  97 Frames are just forwarded from one interface to the other.
  98 In the case of testpmd, the source and destination MAC are rewritten, which corresponds to the mac forwarding mode (--forward-mode=mac).
  99 In the case of VPP, VPP will act as a real L3 router, and the packets are routed from one port to the other using static routes.
 100
 101 Which forwarder and what Nova flavor to use can be selected in the NFVbench configuration. Be default the DPDK testpmd forwarder is used with 2 vCPU per VM.
 102 The configuration of these forwarders (such as MAC rewrite configuration or static route configuration) is managed by NFVbench.
 103
 104
 105 PVP Packet Path
 106 ^^^^^^^^^^^^^^^
 107
 108 This packet path represents a single service chain with 1 loopback VNF and 2 Neutron networks:
 109
 110 .. image:: images/nfvbench-pvp.png
 111
 112
 113 PVVP Packet Path
 114 ^^^^^^^^^^^^^^^^
 115
 116 This packet path represents a single service chain with 2 loopback VNFs in sequence and 3 Neutron networks.
 117 The 2 VNFs will only run on the same compute node (PVVP intra-node):
 118
 119 .. image:: images/nfvbench-pvvp.png
 120
 121
 122 Multi-Chaining (N*PVP or N*PVVP)
 123 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 124
 125 Multiple service chains can be setup by NFVbench without any limit on the concurrency (other than limits imposed by available resources on compute nodes).
 126 In the case of multiple service chains, NFVbench will instruct the traffic generator to use multiple L3 packet streams (frames directed to each path will
 127 have a unique destination MAC address).
 128
 129 Example of multi-chaining with 2 concurrent PVP service chains:
 130
 131 .. image:: images/nfvbench-npvp.png
 132
 133 This innovative feature will allow to measure easily the performance of a fully loaded compute node running multiple service chains.
 134
 135 Multi-chaining is currently limited to 1 compute node (VMs run on the same compute node).
 136 The 2 edge interfaces for all service chains can either share the same 2 networks or can use
 137 dedicated networks (based on a configuration option).
 138 The total traffic will be split equally across all chains.
 139
 140
 141 SR-IOV
 142 ^^^^^^
 143
 144 By default, service chains will be based on virtual switch interfaces.
 145
 146 NFVbench provides an option to select SR-IOV based virtual interfaces instead (thus bypassing any virtual switch) for those OpenStack system that include and support SR-IOV capable NICs on compute nodes.
 147
 148 The PVP packet path will bypass the virtual switch completely when the SR-IOV option is selected:
 149
 150 .. image:: images/nfvbench-sriov-pvp.png
 151
 152 The PVVP packet path will use SR-IOV for the left and right networks and the virtual switch for the middle network by default:
 153
 154 .. image:: images/nfvbench-sriov-pvvp.png
 155
 156 Or in the case of inter-node:
 157
 158 .. image:: images/nfvbench-sriov-pvvp2.png
 159
 160 This packet path is a good way to approximate VM to VM (V2V) performance (middle network) given the high efficiency of the left and right networks. The V2V throughput will likely be very close to the PVVP throughput while its latency will be very close to the difference between the SR-IOV PVVP latency and the SR-IOV PVP latency.
 161
 162 It is possible to also force the middle network to use SR-IOV (in this version, the middle network is limited to use the same SR-IOV phys net):
 163
 164 .. image:: images/nfvbench-all-sriov-pvvp.png
 165
 166 The chain can also span across 2 nodes with the use of 2 SR-IOV ports in each node:
 167
 168 .. image:: images/nfvbench-all-sriov-pvvp2.png
 169
 170
 171 Other Misc Packet Paths
 172 ^^^^^^^^^^^^^^^^^^^^^^^
 173
 174 P2P (Physical interface to Physical interface - no VM) can be supported using the external chain/L2 forwarding mode.
 175
 176 V2V (VM to VM) is not supported but PVVP provides a more complete (and more realistic) alternative.
 177
 178 PVP chain with L3 routers in the path can be supported using PVP chain with L3 forwarding mode (l3_router option). See PVP L3 Router Internal Chain section for more details.
 179
 180
 181 Supported Neutron Network Plugins and vswitches
 182 -----------------------------------------------
 183
 184 Any Virtual Switch, Any Encapsulation
 185 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 186
 187 NFVbench is agnostic of the virtual switch implementation and has been tested with the following virtual switches:
 188
 189 - ML2/VPP/VLAN (networking-vpp)
 190 - OVS/VLAN and OVS-DPDK/VLAN
 191 - ML2/ODL/VPP (OPNFV Fast Data Stack)
 192
 193
 194
 195 Limitations
 196 ***********
 197 VxLAN: latency measurement and per chain stats is not available in the first VxLAN release