OPNFV Project Proposal – Characterize vSwitch Performance for Telco NFV Use Cases

Version: 1.0 (November 3rd, 2014)

Project Name: Characterize vSwitch Performance for Telco NFV Use Cases

Proposed name for the repository: vswitchperf

Project Categories:

• Integration & Testing

Project description: Many Virtual Network Functions (VNFs) require deterministic behaviour of the Network Functions Virtualization Infrastructure (NFVI). Although not being a required component in the NFVI, many cloud and telco infrastructure providers are evaluating a virtual switch as a component of the NFVI in order to direct frames into VNFs. Open vSwitch and other virtual switches have not typically been designed for Telco NFV use cases that require telco grade determinism in their performance. This project proposes evaluating at least one virtual switch in order to understand how suitable it is in this environment and to identify any gaps or bottlenecks in order to drive architectural changes to improve vSwitch throughput and determinism.

Scope: While some work has been done to measure the latency and throughput of a number of vswitch use cases (e.g. https://01.org/sites/default/files/downloads/packet-processing/inteldpdkvswitchperformancefigures0.10.0.pdf), these use cases emphasize best-case scenarios which showcase the best possible throughput and best possible latency. In Telco environments, there are many other system-level effects that can reduce the maximum available throughput and increase maximum latency. This project proposes defining and executing an appropriate set of tests in order to objectively measure the current telco characteristics of a virtual switch in the NFVI. The proposal is to use the DPDK userspace datapath implementation at www.openvswitch.org (aka Accelerated OVS) as a starting point however the intent of the project is to facilitate testing of multiple vSwitches, not a single implementation. Thus, a generic suite of tests shall be developed, with no hard dependencies to a single implementation. In addition, the test case suite shall be architecture independent.

The test cases developed in this project shall not form part of a seperate test framework, rather some or all of these tests may be inserted into the Continuous Integration Test Framework and/or the Platform Functionality Test Framework - if a vSwitch becomes a standard component of an OPNFV release.

The following list is not exhaustive but should indicate the type of tests that should be required. It is expected that more will be added.

• All tests should be repeated with the following two deployments which will determine the performance of both the vswitch and the datapath into the VNF:

1. PHY → vSwitch → PHY
2. PHY → vSwitch → VNF → vSwitch → PHY

• All tests should be carried out using RFC 2544 0% packet loss throughput and latency testing. These tests should be carried out over a long period in order to determine are there any spikes in latency that happen intermittently.

• A single high frame rate flow should be passed through the system. During this time, many flows should be added and removed from the datapath and the performance measured in order to determine how much coupling there is between the datapath and the control path in the virtual switch.

• A large number of flows should be passed through the system at a high rate. The performance should be measured in order to determine how scalable the datapath is in the presence of a large number of flows. The number of flows should be varied for different tests. The match criteria should also be varied.

• A single high frame rate flow should be passed through the system. During this time, a memory intensive process should be run (perhaps on another core) in order to determine the effect of cache sharing and memory bw between process on the vswitch performance.

• In some vswitch architectures, the first packets of a flow that arrive in the system take longer to process than subsequent packets. The packet latency for each of these types of packets should be determined. These tests should also confirm that packets within a flow are not reordered.

• A large number of flows should be passed through the system at a high rate. Simultaneously, a memory intensive workload should be executed on the system.

• A large number of flows should be passed through the system at a high rate. Simultaneously, a compute intensive workload should be executed on the system.

As new requirements become apparent, the suite of test cases could and should be extended.

These tests would subsequently need to be executed in the context of higher level Telco NFV use cases, which would exercise the vSwitch and prove that its underlying characteristics and behaviour can be measured and validated using the tests above. Potential Telco VNF candidates that could be utilised in a subsequent testing phase might be:

• EPC Network Functions, MME, SGW, PGW (vEPC)
• Virtual BRAS (vBRAS)

Documentation:

• vSwitch test case definitions

Dependencies:

• There are currently no similar projects underway or proposed in either OPNFV or in an upstream project.

• The relevant upstream project for this contribution is the DPDK userspace datapath workstream at www.openvswitch.org.

• In terms of external fora or standard development organization dependencies to the project, there are no hard dependencies.

• For the integration and test requirements, there is a dependency towards IA server Hardware and NICs being available to the committers. In addition, there is a dependancy to an Avago PCIe NIC Accelerator card which can also be used to characterise the performance.

• To test the vSwitch subsequently within the context of Telco NFV use cases, there is a dependency on the availability of e.g. vBRAS or vEPC Virtual Network Functions. This can be via either open source VNFs (first preference for flexibility reasons), or proprietary VNFs, as long as they comply with an open interface. This Telco NFV use case testing could potentially be done within the NFVI+VIM test bed project.

Committers and Contributors:

• Committers: Maryam Tahhan: maryam.tahhan@intel.com, Chen Jinzhou: chenjinzhou@huawei.com, Wang Xiao: randy.wang@huawei.com, Christoph Meyer: christoph.meyer@ericsson.com, Madhu Challa: challa@noironetworks.com, Thomas Graf: tgraf@noironetworks.com, Gene Sneider: Eugene.Snider@huawei.com,Wenjing Chu: Wenjing_Chu@DELL.com, Mark Lambe: Mark.Lambe@aeroflex.com, Aihua Li: aihua.li@huawei.com, Tim Irnich: tim.irnich@ericsson.com

• Other contributors: Tapio Tallgren: tapio.tallgren@nsn.com, Petteri Ylä-Outinen: petteri.yla-outinen@nsn.com , Mike Lynch: Michael.a.lynch@intel.com, John Browne: john.j.browne@intel.com Trevor Cooper: trevor.cooper@intel.com, Raghu Kondapalli: raghu.kondapalli@avagotech.com, Sean Chen: s.chen@huawei.com, Aihua Li: aihua.li@huawei.com, Mario Cho: hephaex@gmail.com, Mark Gray: Mark.d.gray@intel.com, Kevin Traynor: Kevin.traynor@intel.com

Planned deliverables:

1. Generic Test plan for characterizing vSwitch performance.
2. Test cases (including test code and scripts) for characterizing vSwitch performance.
3. Performance data showing throughput and determinism of the vSwitch for test cases defined in bullet 1 above. OPNFV Test Lab infrastructure support via associated VNF testing to benchmark and demonstrate throughput and determinism performance using Telco VNFs (e.g. vBRAS, vEPC).
4. Benchmarking data.

The intent is that the output of this project will form a baseline and platform for vSwitch architectural and functional modifications to be proposed in a seperate project. This subsequent project should be focused on implementing the necessary changes to the vSwitch to enable it to meet Telco-grade throughput and determinism targets necessary for in-field NFV deployments. To that end, this current performance characterization project should be seen as a foundational element for such a follow on project.

Proposed Release Schedule:

• The deliverables from this project are targeted for Q1 2015. This is aligned with OPNFV Release 1.0.