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
8 Data Plane Performance Measurement Features
9 -------------------------------------------
11 NFVbench supports the following main measurement capabilities:
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
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)
23 NDR is the highest throughput achieved without dropping packets.
24 PDR is the highest throughput achieved without dropping more than a pre-set limit (called PDR threshold or allowance, expressed in %).
26 Results of each run include the following data:
28 - Aggregated achieved throughput in bps
29 - Aggregated achieved packet rate in pps (or fps)
30 - Actual drop rate in %
31 - Latency in usec (min, max, average in the current version)
33 Built-in OpenStack support
34 --------------------------
35 NFVbench can stage OpenStack resources to build 1 or more service chains using direct OpenStack APIs. Each service chain is composed of:
37 - 1 or 2 loopback VM instances per service chain
38 - 2 Neutron networks per loopback VM
40 OpenStack resources are staged before traffic is measured using OpenStack APIs (Nova and Neutron) then disposed after completion of measurements.
42 The loopback VM flavor to use can be configured in the NFVbench configuration file.
44 Note that NFVbench does not use OpenStack Heat nor any higher level service (VNFM or NFVO) to create the service chains because its
45 main purpose is to measure the performance of the NFVi infrastructure which is mainly focused on L2 forwarding performance.
49 NFVbench also supports settings that involve externally staged packet paths with or without OpenStack:
51 - 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)
52 - run benchmarks on existing L2 chains that are configured externally (e.g. pure L2 forwarder such as DPDK testpmd)
58 NFVbench currently integrates with the open source TRex traffic generator:
60 - `TRex <https://trex-tgn.cisco.com>`_ (pre-built into the NFVbench container)
63 Supported Packet Paths
64 ----------------------
65 Packet paths describe where packets are flowing in the NFVi platform. The most commonly used paths are identified by 3 or 4 letter abbreviations.
66 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.
68 The following packet paths are currently supported by NFVbench:
70 - PVP (Physical interface to VM to Physical interface)
71 - PVVP (Physical interface to VM to VM to Physical interface)
72 - N*PVP (N concurrent PVP packet paths)
73 - N*PVVP (N concurrent PVVP packet paths)
75 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.
81 NFVbench provides a loopback VM image that runs CentOS with 2 pre-installed forwarders:
83 - DPDK testpmd configured to do L2 cross connect between 2 virtual interfaces
84 - FD.io VPP configured to perform L3 routing between 2 virtual interfaces
86 Frames are just forwarded from one interface to the other.
87 In the case of testpmd, the source and destination MAC are rewritten, which corresponds to the mac forwarding mode (--forward-mode=mac).
88 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.
90 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.
91 The configuration of these forwarders (such as MAC rewrite configuration or static route configuration) is managed by NFVbench.
97 This packet path represents a single service chain with 1 loopback VNF and 2 Neutron networks:
99 .. image:: images/nfvbench-pvp.svg
105 This packet path represents a single service chain with 2 loopback VNFs in sequence and 3 Neutron networks.
106 The 2 VNFs can run on the same compute node (PVVP intra-node):
108 .. image:: images/nfvbench-pvvp-intra.svg
110 or on different compute nodes (PVVP inter-node) based on a configuration option:
112 .. image:: images/nfvbench-pvvp-inter.svg
116 Multi-Chaining (N*PVP or N*PVVP)
117 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
119 Multiple service chains can be setup by NFVbench without any limit on the concurrency (other than limits imposed by available resources on compute nodes).
120 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 have a unique destination MAC address).
122 Example of multi-chaining with 2 concurrent PVP service chains:
124 .. image:: images/nfvbench-npvp.svg
126 This innovative feature will allow to measure easily the performance of a fully loaded compute node running multiple service chains.
128 Multi-chaining is currently limited to 1 compute node (PVP or PVVP intra-node) or 2 compute nodes (for PVVP inter-node).
129 The 2 edge interfaces for all service chains will share the same 2 networks.
132 Other Misc Packet Paths
133 ^^^^^^^^^^^^^^^^^^^^^^^
135 P2P (Physical interface to Physical interface - no VM) can be supported using the external chain/L2 forwarding mode.
137 V2V (VM to VM) is not supported but PVVP provides a more complete (and mroe realistic) alternative.
140 Supported Neutron Network Plugins and vswitches
141 -----------------------------------------------
143 Any Virtual Switch, Any Encapsulation
144 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
146 NFVbench is agnostic of the virtual switch implementation and has been tested with the following virtual switches:
148 - ML2/VPP/VLAN (networking-vpp)
149 - OVS/VLAN and OVS-DPDK/VLAN
150 - ML2/ODL/VPP (OPNFV Fast Data Stack)
155 By default, service chains will be based on virtual switch interfaces.
157 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.