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 NFVbench: A Network Performance Benchmarking Tool for NFVi Full Stacks
   6 **********************************************************************
   7
   8 The NFVbench tool provides an automated way to measure the network performance for the most common data plane packet flows
   9 on any NFVi system viewed as a black box (NFVi Full Stack).
  10 An NFVi full stack exposes the following interfaces:
  11 - an OpenStack API for those NFVi platforms based on OpenStack
  12 - an interface to send and receive packets on the data plane (typically through top of rack switches while simpler direct wiring to a looping device would also work)
  13
  14 The NFVi full stack can be any functional OpenStack system that provides the above interfaces.
  15 NFVbench can also be used without OpenStack on any networking device that can handle L2 forwarding or L3 routing.
  16
  17 NFVbench can be installed standalone (in the form of a single Docker container) and is fully functional without
  18 the need to install any other OPNFV tool.
  19
  20 It is designed to be easy to install and easy to use by non experts (no need to be an expert in traffic generators and data plane
  21 performance benchmarking). NFVbench integrates with the open source traffic generator TRex and provides the following benefits when compared
  22 to using a traffic generator directly:
  23
  24 - yaml configuration driven benchmark runs
  25 - CLI or REST front end
  26 - finds highest throughput based on drop rate requirement using an optimized binary search with very fast convergence time
  27 - supports multi-chaining or dense VNF throughput measurement (e.g. find the throughput of a compute node running 20 loopback VNFs)
  28 - detailed stats itemized per VNF chain in text or JSON format
  29 - takes care of configuring packet flows and streams (often hard to use and specific to each gtraffic generator)
  30 - takes care of bring up loopback VNFs/chains using Nova/Neutron/Glance OpenStack APIs
  31 - saves you the hassle of searching what to measure, how to measure and how to interpret resuls
  32
  33 Data Plane Performance Measurement Features
  34 -------------------------------------------
  35
  36 NFVbench supports the following main measurement capabilities:
  37
  38 - supports 2 measurement modes:
  39     - *fixed rate* mode to generate traffic at a fixed rate for a fixed duration
  40     - NDR (No Drop Rate) and PDR (Partial Drop Rate) measurement mode
  41 - configurable frame sizes (any list of fixed sizes or 'IMIX')
  42 - built-in packet paths (PVP, PVVP)
  43 - built-in loopback VNFs based on fast L2 or L3 forwarders running in VMs
  44 - configurable number of flows and service chains
  45 - configurable traffic direction (single or bi-directional)
  46 - can support optional VLAN tagging (dot1q) or VxLAN overlays
  47
  48 NDR is the highest throughput achieved without dropping packets.
  49 PDR is the highest throughput achieved without dropping more than a pre-set limit (called PDR threshold or allowance, expressed in %).
  50
  51 Results of each run include the following data:
  52
  53 - Aggregated achieved bit rate throughput in bps
  54 - Aggregated achieved packet rate in pps (or fps)
  55 - Actual drop rate in %
  56 - Latency in usec (min, max, average in the current version)
  57
  58 Built-in OpenStack support (optional)
  59 -------------------------------------
  60 NFVbench can optionally stage OpenStack resources to build 1 or more service chains using direct OpenStack APIs. Each service chain is composed of:
  61
  62 - 1 or 2 loopback VM instances per service chain
  63 - 2 Neutron networks per loopback VM
  64
  65 OpenStack resources are staged before traffic is measured using OpenStack APIs (Nova and Neutron) then disposed after completion of measurements.
  66
  67 The loopback VM flavor to use can be configured in the NFVbench configuration file.
  68
  69 Note that NFVbench does not use OpenStack Heat nor any higher level service (VNFM or NFVO) to create the service chains because its
  70 main purpose is to measure the performance of the NFVi infrastructure which is mainly focused on L2 forwarding performance.
  71
  72 External Chains
  73 ---------------
  74 NFVbench supports settings that involve externally staged packet paths with or without OpenStack:
  75
  76 - 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)
  77 - run benchmarks on existing L2 chains that are configured externally (e.g. pure L2 forwarder such as DPDK testpmd)
  78
  79 Direct L2 Loopback (Switch or wire loopback)
  80 --------------------------------------------
  81 NFVbench supports benchmarking of pure L2 loopbacks (see "--l2-loopback vlan" option)
  82
  83 - Switch level loopback
  84 - Port to port wire loopback
  85
  86 In this mode, NFVbench will take a vlan ID and send packets from each port to the other port
  87 (dest MAC set to the other port MAC) using the same VLAN ID on both ports.
  88 This can be useful for example to verify that the connectivity to the switch is working properly.
  89
  90 Traffic Generation
  91 ------------------
  92
  93 NFVbench currently integrates with the open source TRex traffic generator:
  94
  95 - `TRex <https://github.com/cisco-system-traffic-generator/trex-core>`_ (pre-built into the NFVbench container)
  96
  97
  98 Supported Packet Paths
  99 ----------------------
 100 Packet paths describe where packets are flowing in the NFVi platform. The most commonly used paths are identified by 3 or 4 letter abbreviations.
 101 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.
 102
 103 The following packet paths are currently supported by NFVbench:
 104
 105 - PVP (Physical interface to VM to Physical interface)
 106 - PVVP (Physical interface to VM to VM to Physical interface)
 107 - N*PVP (N concurrent PVP packet paths)
 108 - N*PVVP (N concurrent PVVP packet paths)
 109
 110 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.
 111
 112
 113 Loopback VM
 114 ^^^^^^^^^^^
 115
 116 NFVbench provides a loopback VM image that runs CentOS with 2 pre-installed forwarders:
 117
 118 - DPDK testpmd configured to do L2 cross connect between 2 virtual interfaces
 119 - FD.io VPP configured to perform L3 routing between 2 virtual interfaces
 120
 121 Frames are just forwarded from one interface to the other.
 122 In the case of testpmd, the source and destination MAC are rewritten, which corresponds to the mac forwarding mode (--forward-mode=mac).
 123 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.
 124
 125 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.
 126 The configuration of these forwarders (such as MAC rewrite configuration or static route configuration) is managed by NFVbench.
 127
 128 Importance of Dense VNF Measurement
 129 -----------------------------------
 130 Production deployments of NFVi stacks can require to run a large number of VMs per compute node in order to fully utilize all the
 131 hardware resources available in each of these compute nodes.
 132 Given that optimization of a compute node can be very different based on the number of VMs, it is therefore critical
 133 to do performance benchmarking at scale.
 134 NFVbench has been the first benchmarking tool to recognize this and to provide dense VNF dataplane benchmarking
 135 by staging multipe chains using OpenStack and configuring the traffic generator to split the traffic
 136 across all configured chains. This kind of measurement is very time consuming to do directly with traffic generators
 137 as it requires understanding how traffic is shaped in order to cover all chains in a balanced way.
 138
 139 PVP Packet Path
 140 ^^^^^^^^^^^^^^^
 141
 142 This packet path represents a single service chain with 1 loopback VNF and 2 Neutron networks:
 143
 144 .. image:: images/nfvbench-pvp.png
 145
 146
 147 PVVP Packet Path
 148 ^^^^^^^^^^^^^^^^
 149
 150 This packet path represents a single service chain with 2 loopback VNFs in sequence and 3 Neutron networks.
 151 The 2 VNFs will only run on the same compute node (PVVP intra-node):
 152
 153 .. image:: images/nfvbench-pvvp.png
 154
 155
 156 Dense VNF or Multi-Chaining (N*PVP or N*PVVP)
 157 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 158
 159 Multiple service chains can be setup by NFVbench without any limit on the concurrency (other than limits imposed by available resources on compute nodes).
 160 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
 161 have a unique destination MAC address).
 162
 163 Example of multi-chaining with 2 concurrent PVP service chains:
 164
 165 .. image:: images/nfvbench-npvp.png
 166
 167 This innovative feature will allow to measure easily the performance of a fully loaded compute node running multiple service chains.
 168
 169 Multi-chaining is currently limited to 1 compute node (VMs run on the same compute node).
 170 The 2 edge interfaces for all service chains can either share the same 2 networks or can use
 171 dedicated networks (based on a configuration option).
 172 The total traffic will be split equally across all chains.
 173
 174
 175 SR-IOV
 176 ^^^^^^
 177
 178 By default, service chains will be based on virtual switch interfaces.
 179
 180 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.
 181
 182 The PVP packet path will bypass the virtual switch completely when the SR-IOV option is selected:
 183
 184 .. image:: images/nfvbench-sriov-pvp.png
 185
 186 The PVVP packet path will use SR-IOV for the left and right networks and the virtual switch for the middle network by default:
 187
 188 .. image:: images/nfvbench-sriov-pvvp.png
 189
 190 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.
 191
 192 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):
 193
 194 .. image:: images/nfvbench-all-sriov-pvvp.png
 195
 196
 197 Other Misc Packet Paths
 198 ^^^^^^^^^^^^^^^^^^^^^^^
 199
 200 P2P (Physical interface to Physical interface - no VM) can be supported using the external chain/L2 forwarding mode.
 201
 202 V2V (VM to VM) is not supported but PVVP provides a more complete (and more realistic) alternative.
 203
 204 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.
 205
 206
 207 Supported Neutron Network Plugins and vswitches
 208 -----------------------------------------------
 209
 210 Any Virtual Switch, Any Encapsulation
 211 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 212
 213 NFVbench is agnostic of the virtual switch implementation and has been tested with the following virtual switches:
 214
 215 - ML2/VPP/VLAN (networking-vpp)
 216 - OVS/VLAN and OVS-DPDK/VLAN
 217 - ML2/ODL/VPP (OPNFV Fast Data Stack)
 218
 219
 220 Limitations
 221 ***********
 222 VxLAN: latency measurement is not available in the current VxLAN release
 223 PVVP Inter-node (where the 2 VMs are running on diofferent compute nodes) is no longer supported