diff options
23 files changed, 138 insertions, 5089 deletions
@@ -2,8 +2,8 @@ Project: Data-plane performance testing and benchmarking Creation Date: December 16th, 2014 Category: Integration & Testing Lifecycle State: Mature -Primary Contact: Trevor Cooper -Project Lead: (Trevor Cooper) trevor.cooper@intel.com +Primary Contact: Sridhar Rao +Project Lead: (Sridhar Rao) sridhar.rao@spirent.com Jira name vSwitch Characterization JIRA tag : VSPERF Repository: vswitchperf diff --git a/conf/02_vswitch.conf b/conf/02_vswitch.conf index c50a5ddd..92521f9a 100644 --- a/conf/02_vswitch.conf +++ b/conf/02_vswitch.conf @@ -213,7 +213,8 @@ VSWITCH_VPP_ARGS = { 'full-coredump', ], 'cpu' : [ - 'main-core 3', + 'main-core 2', + 'workers 2', 'corelist-workers 4,5', ], } diff --git a/conf/03_traffic.conf b/conf/03_traffic.conf index 5f6d791c..b5533833 100644 --- a/conf/03_traffic.conf +++ b/conf/03_traffic.conf @@ -441,6 +441,8 @@ TRAFFICGEN_TREX_LATENCY_PPS = 1000 # Example 10 Gbps: TRAFFICGEN_TREXINE_SPEED_GBPS = '10' # Today only 10 Gbps is supported TRAFFICGEN_TREX_LINE_SPEED_GBPS = '10' +# FOR SR-IOV or multistream layer 2 tests to work with T-Rex enable Promiscuous mode +TRAFFICGEN_TREX_PROMISCUOUS=False PATHS['trafficgen'] = { 'trex': { 'type' : 'src', diff --git a/conf/10_custom.conf b/conf/10_custom.conf index 6011e6a8..8020bb93 100644 --- a/conf/10_custom.conf +++ b/conf/10_custom.conf @@ -136,6 +136,8 @@ TRAFFICGEN_TREX_LATENCY_PPS = 1000 # Example 10 Gbps: TRAFFICGEN_TREXINE_SPEED_GBPS = '10' # Today only 10 Gbps is supported TRAFFICGEN_TREX_LINE_SPEED_GBPS = '10' +# FOR SR-IOV or multistream layer 2 tests to work with T-Rex enable Promiscuous mode +TRAFFICGEN_TREX_PROMISCUOUS=False # TREX Configuration and Connection Info-- END #################################################### diff --git a/docs/testing/developer/devguide/design/trafficgen_integration_guide.rst b/docs/testing/developer/devguide/design/trafficgen_integration_guide.rst index 7dae19ba..c88b80ed 100644 --- a/docs/testing/developer/devguide/design/trafficgen_integration_guide.rst +++ b/docs/testing/developer/devguide/design/trafficgen_integration_guide.rst @@ -64,16 +64,20 @@ Output should look like: Classes derived from: ITrafficGenerator ====== - * Ixia: A wrapper around the IXIA traffic generator. + * Dummy: A dummy traffic generator whose data is generated by the user. * IxNet: A wrapper around IXIA IxNetwork applications. - * Dummy: A dummy traffic generator whose data is generated by the user. + * Ixia: A wrapper around the IXIA traffic generator. - * SampleTG: A sample traffic generator implementation + * Moongen: Moongen Traffic generator wrapper. * TestCenter: Spirent TestCenter + * Trex: Trex Traffic generator wrapper. + + * Xena: Xena Traffic generator wrapper class + Step 3 - configuration ====================== diff --git a/docs/testing/developer/devguide/design/vswitchperf_design.rst b/docs/testing/developer/devguide/design/vswitchperf_design.rst index 58563845..55614d33 100644 --- a/docs/testing/developer/devguide/design/vswitchperf_design.rst +++ b/docs/testing/developer/devguide/design/vswitchperf_design.rst @@ -131,7 +131,7 @@ the content of PATHS dictionary accordingly. Dictionary has a specific section of configuration options for every tool type, it means: - * ``PATHS['vswitch']`` - contains a separete dictionary for each of vswitches supported by VSPEF + * ``PATHS['vswitch']`` - contains a separate dictionary for each of vswitches supported by VSPEF Example: @@ -277,7 +277,7 @@ TRAFFIC dictionary is used for configuration of traffic generator. Default value can be found in configuration file ``conf/03_traffic.conf``. These default values can be modified by (first option has the highest priorty): - 1. ``Parameters`` section of testcase defintion + 1. ``Parameters`` section of testcase definition 2. command line options specified by ``--test-params`` argument 3. custom configuration file @@ -437,7 +437,7 @@ First option can contain macros starting with ``#`` to generate VM specific valu These macros can be used only for options of ``list`` or ``str`` types with ``GUEST_`` prefix. -Example of macros and their expnasion for 2 VMs: +Example of macros and their expansion for 2 VMs: .. code-block:: python @@ -629,7 +629,7 @@ by deployment name as follows: optional ``number`` of VMs. In case that ``number`` is not specified, then 2 VMs will be used. Multistream feature is used to route traffic to particular VMs (or NIC pairs of every VM). It means, that VSPERF will enable multistream - feaure and sets the number of streams to the number of VMs and their NIC + feature and sets the number of streams to the number of VMs and their NIC pairs. Traffic will be dispatched based on Stream Type, i.e. by UDP port, IP address or MAC address. @@ -710,7 +710,7 @@ bridge inside the VM. VM, vSwitch, Traffic Generator Independence =========================================== -VSPERF supports different vSwithes, Traffic Generators, VNFs +VSPERF supports different VSwitches, Traffic Generators, VNFs and Forwarding Applications by using standard object-oriented polymorphism: * Support for vSwitches is implemented by a class inheriting from IVSwitch. diff --git a/docs/testing/developer/devguide/index.rst b/docs/testing/developer/devguide/index.rst index 236fb3d9..49659792 100644 --- a/docs/testing/developer/devguide/index.rst +++ b/docs/testing/developer/devguide/index.rst @@ -14,13 +14,13 @@ Introduction VSPERF is an OPNFV testing project. -VSPERF is an OPNFV project that provides an automated test-framework and comprehensive test suite based on Industry +VSPERF provides an automated test-framework and comprehensive test suite based on Industry Test Specifications for measuring NFVI data-plane performance. The data-path includes switching technologies with physical and virtual network interfaces. The VSPERF architecture is switch and traffic generator agnostic and test -cases can be easily customized. Software versions and configurations including the vSwitch (OVS or VPP) as well as -the network topology are controlled by VSPERF (independent of OpenStack). VSPERF is used as a development tool for -optimizing switching technologies, qualification of packet processing components and for pre-deployment evaluation -of the NFV platform data-path. +cases can be easily customized. VSPERF was designed to be independent of OpenStack therefore OPNFV installer scenarios +are not required. VSPERF can source, configure and deploy the device-under-test using specified software versions and +network topology. VSPERF is used as a development tool for optimizing switching technologies, qualification of packet +processing functions and for evaluation of data-path performance. The Euphrates release adds new features and improvements that will help advance high performance packet processing on Telco NFV platforms. This includes new test cases, flexibility in customizing test-cases, new results display diff --git a/docs/testing/developer/devguide/requirements/ietf_draft/LICENSE b/docs/testing/developer/devguide/requirements/ietf_draft/LICENSE deleted file mode 100644 index 7fc9ae14..00000000 --- a/docs/testing/developer/devguide/requirements/ietf_draft/LICENSE +++ /dev/null @@ -1,12 +0,0 @@ -Copyright (c) 2016 IETF Trust and the persons identified as the -document authors. All rights reserved. - -This document is subject to BCP 78 and the IETF Trust's Legal -Provisions Relating to IETF Documents -(http://trustee.ietf.org/license-info) in effect on the date of -publication of this document. Please review these documents -carefully, as they describe your rights and restrictions with respect -to this document. Code Components extracted from this document must -include Simplified BSD License text as described in Section 4.e of -the Trust Legal Provisions and are provided without warranty as -described in the Simplified BSD License. diff --git a/docs/testing/developer/devguide/requirements/ietf_draft/draft-ietf-bmwg-vswitch-opnfv-00.xml b/docs/testing/developer/devguide/requirements/ietf_draft/draft-ietf-bmwg-vswitch-opnfv-00.xml deleted file mode 100644 index 2259b23c..00000000 --- a/docs/testing/developer/devguide/requirements/ietf_draft/draft-ietf-bmwg-vswitch-opnfv-00.xml +++ /dev/null @@ -1,1016 +0,0 @@ -<?xml version="1.0" encoding="US-ASCII"?> -<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -<?rfc toc="yes"?> -<?rfc tocompact="yes"?> -<?rfc tocdepth="3"?> -<?rfc tocindent="yes"?> -<?rfc symrefs="yes"?> -<?rfc sortrefs="yes"?> -<?rfc comments="yes"?> -<?rfc inline="yes"?> -<?rfc compact="yes"?> -<?rfc subcompact="no"?> -<rfc category="info" docName="draft-ietf-bmwg-vswitch-opnfv-00" - ipr="trust200902"> - <front> - <title abbrev="Benchmarking vSwitches">Benchmarking Virtual Switches in - OPNFV</title> - - <author fullname="Maryam Tahhan" initials="M." surname="Tahhan"> - <organization>Intel</organization> - - <address> - <postal> - <street/> - - <city/> - - <region/> - - <code/> - - <country/> - </postal> - - <phone/> - - <facsimile/> - - <email>maryam.tahhan@intel.com</email> - - <uri/> - </address> - </author> - - <author fullname="Billy O'Mahony" initials="B." surname="O'Mahony"> - <organization>Intel</organization> - - <address> - <postal> - <street/> - - <city/> - - <region/> - - <code/> - - <country/> - </postal> - - <phone/> - - <facsimile/> - - <email>billy.o.mahony@intel.com</email> - - <uri/> - </address> - </author> - - <author fullname="Al Morton" initials="A." surname="Morton"> - <organization>AT&T Labs</organization> - - <address> - <postal> - <street>200 Laurel Avenue South</street> - - <city>Middletown,</city> - - <region>NJ</region> - - <code>07748</code> - - <country>USA</country> - </postal> - - <phone>+1 732 420 1571</phone> - - <facsimile>+1 732 368 1192</facsimile> - - <email>acmorton@att.com</email> - - <uri>http://home.comcast.net/~acmacm/</uri> - </address> - </author> - - <date day="8" month="July" year="2016"/> - - <abstract> - <t>This memo describes the progress of the Open Platform for NFV (OPNFV) - project on virtual switch performance "VSWITCHPERF". This project - intends to build on the current and completed work of the Benchmarking - Methodology Working Group in IETF, by referencing existing literature. - The Benchmarking Methodology Working Group has traditionally conducted - laboratory characterization of dedicated physical implementations of - internetworking functions. Therefore, this memo begins to describe the - additional considerations when virtual switches are implemented in - general-purpose hardware. The expanded tests and benchmarks are also - influenced by the OPNFV mission to support virtualization of the "telco" - infrastructure.</t> - </abstract> - - <note title="Requirements Language"> - <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in <xref - target="RFC2119">RFC 2119</xref>.</t> - - <t/> - </note> - </front> - - <middle> - <section title="Introduction"> - <t>Benchmarking Methodology Working Group (BMWG) has traditionally - conducted laboratory characterization of dedicated physical - implementations of internetworking functions. The Black-box Benchmarks - of Throughput, Latency, Forwarding Rates and others have served our - industry for many years. Now, Network Function Virtualization (NFV) has - the goal to transform how internetwork functions are implemented, and - therefore has garnered much attention.</t> - - <t>This memo summarizes the progress of the Open Platform for NFV - (OPNFV) project on virtual switch performance characterization, - "VSWITCHPERF", through the Brahmaputra (second) release <xref - target="BrahRel"/>. This project intends to build on the current and - completed work of the Benchmarking Methodology Working Group in IETF, by - referencing existing literature. For example, currently the most often - referenced RFC is <xref target="RFC2544"/> (which depends on <xref - target="RFC1242"/>) and foundation of the benchmarking work in OPNFV is - common and strong.</t> - - <t>See - https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases - for more background, and the OPNFV website for general information: - https://www.opnfv.org/</t> - - <t>The authors note that OPNFV distinguishes itself from other open - source compute and networking projects through its emphasis on existing - "telco" services as opposed to cloud-computing. There are many ways in - which telco requirements have different emphasis on performance - dimensions when compared to cloud computing: support for and transfer of - isochronous media streams is one example.</t> - - <t>Note also that the move to NFV Infrastructure has resulted in many - new benchmarking initiatives across the industry. The authors are - currently doing their best to maintain alignment with many other - projects, and this Internet Draft is one part of the efforts. We - acknowledge the early work in <xref - target="I-D.huang-bmwg-virtual-network-performance"/>, and useful - discussion with the authors.</t> - </section> - - <section title="Scope"> - <t>The primary purpose and scope of the memo is to inform the industry - of work-in-progress that builds on the body of extensive BMWG literature - and experience, and describe the extensions needed for benchmarking - virtual switches. Inital feedback indicates that many of these - extensions may be applicable beyond the current scope (to hardware - switches in the NFV Infrastructure and to virtual routers, for example). - Additionally, this memo serves as a vehicle to include more detail and - commentary from BMWG and other Open Source communities, under BMWG's - chartered work to characterize the NFV Infrastructure (a virtual switch - is an important aspect of that infrastructure).</t> - </section> - - <section title="Benchmarking Considerations"> - <t>This section highlights some specific considerations (from <xref - target="I-D.ietf-bmwg-virtual-net"/>)related to Benchmarks for virtual - switches. The OPNFV project is sharing its present view on these areas, - as they develop their specifications in the Level Test Design (LTD) - document.</t> - - <section title="Comparison with Physical Network Functions"> - <t>To compare the performance of virtual designs and implementations - with their physical counterparts, identical benchmarks are needed. - BMWG has developed specifications for many network functions this memo - re-uses existing benchmarks through references, and expands them - during development of new methods. A key configuration aspect is the - number of parallel cores required to achieve comparable performance - with a given physical device, or whether some limit of scale was - reached before the cores could achieve the comparable level.</t> - - <t>It's unlikely that the virtual switch will be the only application - running on the SUT, so CPU utilization, Cache utilization, and Memory - footprint should also be recorded for the virtual implementations of - internetworking functions.</t> - </section> - - <section title="Continued Emphasis on Black-Box Benchmarks"> - <t>External observations remain essential as the basis for Benchmarks. - Internal observations with fixed specification and interpretation will - be provided in parallel to assist the development of operations - procedures when the technology is deployed.</t> - </section> - - <section title="New Configuration Parameters"> - <t>A key consideration when conducting any sort of benchmark is trying - to ensure the consistency and repeatability of test results. When - benchmarking the performance of a vSwitch there are many factors that - can affect the consistency of results, one key factor is matching the - various hardware and software details of the SUT. This section lists - some of the many new parameters which this project believes are - critical to report in order to achieve repeatability.</t> - - <t>Hardware details including:</t> - - <t><list style="symbols"> - <t>Platform details</t> - - <t>Processor details</t> - - <t>Memory information (type and size)</t> - - <t>Number of enabled cores</t> - - <t>Number of cores used for the test</t> - - <t>Number of physical NICs, as well as their details - (manufacturer, versions, type and the PCI slot they are plugged - into)</t> - - <t>NIC interrupt configuration</t> - - <t>BIOS version, release date and any configurations that were - modified</t> - - <t>CPU microcode level</t> - - <t>Memory DIMM configurations (quad rank performance may not be - the same as dual rank) in size, freq and slot locations</t> - - <t>PCI configuration parameters (payload size, early ack - option...)</t> - - <t>Power management at all levels (ACPI sleep states, processor - package, OS...)</t> - </list>Software details including:</t> - - <t><list style="symbols"> - <t>OS parameters and behavior (text vs graphical no one typing at - the console on one system)</t> - - <t>OS version (for host and VNF)</t> - - <t>Kernel version (for host and VNF)</t> - - <t>GRUB boot parameters (for host and VNF)</t> - - <t>Hypervisor details (Type and version)</t> - - <t>Selected vSwitch, version number or commit id used</t> - - <t>vSwitch launch command line if it has been parameterised</t> - - <t>Memory allocation to the vSwitch</t> - - <t>which NUMA node it is using, and how many memory channels</t> - - <t>DPDK or any other SW dependency version number or commit id - used</t> - - <t>Memory allocation to a VM - if it's from Hugpages/elsewhere</t> - - <t>VM storage type: snapshot/independent persistent/independent - non-persistent</t> - - <t>Number of VMs</t> - - <t>Number of Virtual NICs (vNICs), versions, type and driver</t> - - <t>Number of virtual CPUs and their core affinity on the host</t> - - <t>Number vNIC interrupt configuration</t> - - <t>Thread affinitization for the applications (including the - vSwitch itself) on the host</t> - - <t>Details of Resource isolation, such as CPUs designated for - Host/Kernel (isolcpu) and CPUs designated for specific processes - (taskset). - Test duration. - Number of flows.</t> - </list></t> - - <t>Test Traffic Information:<list style="symbols"> - <t>Traffic type - UDP, TCP, IMIX / Other</t> - - <t>Packet Sizes</t> - - <t>Deployment Scenario</t> - </list></t> - - <t/> - </section> - - <section title="Flow classification"> - <t>Virtual switches group packets into flows by processing and - matching particular packet or frame header information, or by matching - packets based on the input ports. Thus a flow can be thought of a - sequence of packets that have the same set of header field values - (5-tuple) or have arrived on the same port. Performance results can - vary based on the parameters the vSwitch uses to match for a flow. The - recommended flow classification parameters for any vSwitch performance - tests are: the input port, the source IP address, the destination IP - address and the Ethernet protocol type field. It is essential to - increase the flow timeout time on a vSwitch before conducting any - performance tests that do not measure the flow setup time. Normally - the first packet of a particular stream will install the flow in the - virtual switch which adds an additional latency, subsequent packets of - the same flow are not subject to this latency if the flow is already - installed on the vSwitch.</t> - </section> - - <section title="Benchmarks using Baselines with Resource Isolation"> - <t>This outline describes measurement of baseline with isolated - resources at a high level, which is the intended approach at this - time.</t> - - <t><list style="numbers"> - <t>Baselines: <list style="symbols"> - <t>Optional: Benchmark platform forwarding capability without - a vswitch or VNF for at least 72 hours (serves as a means of - platform validation and a means to obtain the base performance - for the platform in terms of its maximum forwarding rate and - latency). <figure> - <preamble>Benchmark platform forwarding - capability</preamble> - - <artwork align="right"><![CDATA[ __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | Simple Forwarding App | | Host - | | | | | - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - - <postamble/> - </figure></t> - - <t>Benchmark VNF forwarding capability with direct - connectivity (vSwitch bypass, e.g., SR/IOV) for at least 72 - hours (serves as a means of VNF validation and a means to - obtain the base performance for the VNF in terms of its - maximum forwarding rate and latency). The metrics gathered - from this test will serve as a key comparison point for - vSwitch bypass technologies performance and vSwitch - performance. <figure align="right"> - <preamble>Benchmark VNF forwarding capability</preamble> - - <artwork><![CDATA[ __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | VNF | | | - | | | | | - | +------------------------------------------+ | | - | | Passthrough/SR-IOV | | Host - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - - <postamble/> - </figure></t> - - <t>Benchmarking with isolated resources alone, with other - resources (both HW&SW) disabled Example, vSw and VM are - SUT</t> - - <t>Benchmarking with isolated resources alone, leaving some - resources unused</t> - - <t>Benchmark with isolated resources and all resources - occupied</t> - </list></t> - - <t>Next Steps<list style="symbols"> - <t>Limited sharing</t> - - <t>Production scenarios</t> - - <t>Stressful scenarios</t> - </list></t> - </list></t> - </section> - </section> - - <section title="VSWITCHPERF Specification Summary"> - <t>The overall specification in preparation is referred to as a Level - Test Design (LTD) document, which will contain a suite of performance - tests. The base performance tests in the LTD are based on the - pre-existing specifications developed by BMWG to test the performance of - physical switches. These specifications include:</t> - - <t><list style="symbols"> - <t><xref target="RFC2544"/> Benchmarking Methodology for Network - Interconnect Devices</t> - - <t><xref target="RFC2889"/> Benchmarking Methodology for LAN - Switching</t> - - <t><xref target="RFC6201"/> Device Reset Characterization</t> - - <t><xref target="RFC5481"/> Packet Delay Variation Applicability - Statement</t> - </list></t> - - <t>Some of the above/newer RFCs are being applied in benchmarking for - the first time, and represent a development challenge for test equipment - developers. Fortunately, many members of the testing system community - have engaged on the VSPERF project, including an open source test - system.</t> - - <t>In addition to this, the LTD also re-uses the terminology defined - by:</t> - - <t><list style="symbols"> - <t><xref target="RFC2285"/> Benchmarking Terminology for LAN - Switching Devices</t> - - <t><xref target="RFC5481"/> Packet Delay Variation Applicability - Statement</t> - </list></t> - - <t/> - - <t>Specifications to be included in future updates of the LTD - include:<list style="symbols"> - <t><xref target="RFC3918"/> Methodology for IP Multicast - Benchmarking</t> - - <t><xref target="RFC4737"/> Packet Reordering Metrics</t> - </list></t> - - <t>As one might expect, the most fundamental internetworking - characteristics of Throughput and Latency remain important when the - switch is virtualized, and these benchmarks figure prominently in the - specification.</t> - - <t>When considering characteristics important to "telco" network - functions, we must begin to consider additional performance metrics. In - this case, the project specifications have referenced metrics from the - IETF IP Performance Metrics (IPPM) literature. This means that the <xref - target="RFC2544"/> test of Latency is replaced by measurement of a - metric derived from IPPM's <xref target="RFC2679"/>, where a set of - statistical summaries will be provided (mean, max, min, etc.). Further - metrics planned to be benchmarked include packet delay variation as - defined by <xref target="RFC5481"/> , reordering, burst behaviour, DUT - availability, DUT capacity and packet loss in long term testing at - Throughput level, where some low-level of background loss may be present - and characterized.</t> - - <t>Tests have been (or will be) designed to collect the metrics - below:</t> - - <t><list style="symbols"> - <t>Throughput Tests to measure the maximum forwarding rate (in - frames per second or fps) and bit rate (in Mbps) for a constant load - (as defined by <xref target="RFC1242"/>) without traffic loss.</t> - - <t>Packet and Frame Delay Distribution Tests to measure average, min - and max packet and frame delay for constant loads.</t> - - <t>Packet Delay Tests to understand latency distribution for - different packet sizes and over an extended test run to uncover - outliers.</t> - - <t>Scalability Tests to understand how the virtual switch performs - as the number of flows, active ports, complexity of the forwarding - logic’s configuration… it has to deal with - increases.</t> - - <t>Stream Performance Tests (TCP, UDP) to measure bulk data transfer - performance, i.e. how fast systems can send and receive data through - the switch.</t> - - <t>Control Path and Datapath Coupling Tests, to understand how - closely coupled the datapath and the control path are as well as the - effect of this coupling on the performance of the DUT (example: - delay of the initial packet of a flow).</t> - - <t>CPU and Memory Consumption Tests to understand the virtual - switch’s footprint on the system, usually conducted as - auxiliary measurements with benchmarks above. They include: CPU - utilization, Cache utilization and Memory footprint.</t> - - <t>The so-called "Soak" tests, where the selected test is conducted - over a long period of time (with an ideal duration of 24 hours, and - at least 6 hours). The purpose of soak tests is to capture transient - changes in performance which may occur due to infrequent processes - or the low probability coincidence of two or more processes. The - performance must be evaluated periodically during continuous - testing, and this results in use of <xref target="RFC2889"/> Frame - Rate metrics instead of <xref target="RFC2544"/> Throughput (which - requires stopping traffic to allow time for all traffic to exit - internal queues).</t> - </list></t> - - <t>Future/planned test specs include:<list style="symbols"> - <t>Request/Response Performance Tests (TCP, UDP) which measure the - transaction rate through the switch.</t> - - <t>Noisy Neighbour Tests, to understand the effects of resource - sharing on the performance of a virtual switch.</t> - - <t>Tests derived from examination of ETSI NFV Draft GS IFA003 - requirements <xref target="IFA003"/> on characterization of - acceleration technologies applied to vswitches.</t> - </list>The flexibility of deployment of a virtual switch within a - network means that the BMWG IETF existing literature needs to be used to - characterize the performance of a switch in various deployment - scenarios. The deployment scenarios under consideration include:</t> - - <t><figure> - <preamble>Physical port to virtual switch to physical - port</preamble> - - <artwork><![CDATA[ __ - +--------------------------------------------------+ | - | +--------------------+ | | - | | | | | - | | v | | Host - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure></t> - - <t><figure> - <preamble>Physical port to virtual switch to VNF to virtual switch - to physical port</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ : | | - | | | | | Guest - | : v | | - | +---------------+ +---------------+ | | - | | logical port 0| | logical port 1| | | - +---+---------------+-----------+---------------+---+ __| - ^ : - | | - : v __ - +---+---------------+----------+---------------+---+ | - | | logical port 0| | logical port 1| | | - | +---------------+ +---------------+ | | - | ^ : | | - | | | | | Host - | : v | | - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>Physical port to virtual switch to VNF to virtual switch - to VNF to virtual switch to physical port</preamble> - - <artwork><![CDATA[ __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | ^ | | | ^ | | | - | | v | | | v | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 1 | | | | 0 1 | | | - +---+---------------+--+ +---+---------------+--+__| - ^ : ^ : - | | | | - : v : v _ - +---+---------------+---------+---------------+--+ | - | | 0 1 | | 3 4 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | ^ | ^ | | | Host - | | |-----------------| v | | - | +--------------+ +--------------+ | | - | | phy ports | vSwitch | phy ports | | | - +---+--------------+----------+--------------+---+_| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>Physical port to virtual switch to VNF</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ | | - | | | | Guest - | : | | - | +---------------+ | | - | | logical port 0| | | - +---+---------------+-------------------------------+ __| - ^ - | - : __ - +---+---------------+------------------------------+ | - | | logical port 0| | | - | +---------------+ | | - | ^ | | - | | | | Host - | : | | - | +--------------+ | | - | | phy port | vSwitch | | - +---+--------------+------------ -------------- ---+ __| - ^ - | - : - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>VNF to virtual switch to physical port</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | : | | - | | | | Guest - | v | | - | +---------------+ | | - | | logical port | | | - +-------------------------------+---------------+---+ __| - : - | - v __ - +------------------------------+---------------+---+ | - | | logical port | | | - | +---------------+ | | - | : | | - | | | | Host - | v | | - | +--------------+ | | - | vSwitch | phy port | | | - +-------------------------------+--------------+---+ __| - : - | - v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>VNF to virtual switch to VNF</preamble> - - <artwork><![CDATA[ __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | | | | ^ | | - | v | | | | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 | | | | 0 | | | - +---+---------------+--+ +---+---------------+--+__| - : ^ - | | - v : _ - +---+---------------+---------+---------------+--+ | - | | 1 | | 1 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | | ^ | | Host - | L-----------------+ | | - | | | - | vSwitch | | - +------------------------------------------------+_|]]></artwork> - </figure></t> - - <t>A set of Deployment Scenario figures is available on the VSPERF Test - Methodology Wiki page <xref target="TestTopo"/>.</t> - </section> - - <section title="3x3 Matrix Coverage"> - <t>This section organizes the many existing test specifications into the - "3x3" matrix (introduced in <xref target="I-D.ietf-bmwg-virtual-net"/>). - Because the LTD specification ID names are quite long, this section is - organized into lists for each occupied cell of the matrix (not all are - occupied, also the matrix has grown to 3x4 to accommodate scale metrics - when displaying the coverage of many metrics/benchmarks). The current - version of the LTD specification is available <xref target="LTD"/>.</t> - - <t>The tests listed below assess the activation of paths in the data - plane, rather than the control plane.</t> - - <t>A complete list of tests with short summaries is available on the - VSPERF "LTD Test Spec Overview" Wiki page <xref target="LTDoverV"/>.</t> - - <section title="Speed of Activation"> - <t><list style="symbols"> - <t>Activation.RFC2889.AddressLearningRate</t> - - <t>PacketLatency.InitialPacketProcessingLatency</t> - </list></t> - </section> - - <section title="Accuracy of Activation section"> - <t><list style="symbols"> - <t>CPDP.Coupling.Flow.Addition</t> - </list></t> - </section> - - <section title="Reliability of Activation"> - <t><list style="symbols"> - <t>Throughput.RFC2544.SystemRecoveryTime</t> - - <t>Throughput.RFC2544.ResetTime</t> - </list></t> - </section> - - <section title="Scale of Activation"> - <t><list style="symbols"> - <t>Activation.RFC2889.AddressCachingCapacity</t> - </list></t> - </section> - - <section title="Speed of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2544.PacketLossRate</t> - - <t>CPU.RFC2544.0PacketLoss</t> - - <t>Throughput.RFC2544.PacketLossRateFrameModification</t> - - <t>Throughput.RFC2544.BackToBackFrames</t> - - <t>Throughput.RFC2889.MaxForwardingRate</t> - - <t>Throughput.RFC2889.ForwardPressure</t> - - <t>Throughput.RFC2889.BroadcastFrameForwarding</t> - </list></t> - </section> - - <section title="Accuracy of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2889.ErrorFramesFiltering</t> - - <t>Throughput.RFC2544.Profile</t> - </list></t> - </section> - - <section title="Reliability of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2889.Soak</t> - - <t>Throughput.RFC2889.SoakFrameModification</t> - - <t>PacketDelayVariation.RFC3393.Soak</t> - </list></t> - </section> - - <section title="Scalability of Operation"> - <t><list style="symbols"> - <t>Scalability.RFC2544.0PacketLoss</t> - - <t>MemoryBandwidth.RFC2544.0PacketLoss.Scalability</t> - </list></t> - </section> - - <section title="Summary"> - <t><figure> - <artwork><![CDATA[|------------------------------------------------------------------------| -| | | | | | -| | SPEED | ACCURACY | RELIABILITY | SCALE | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Activation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Operation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| De-activation | | | | | -| | | | | | -|------------------------------------------------------------------------|]]></artwork> - </figure></t> - </section> - </section> - - <section title="Security Considerations"> - <t>Benchmarking activities as described in this memo are limited to - technology characterization of a Device Under Test/System Under Test - (DUT/SUT) using controlled stimuli in a laboratory environment, with - dedicated address space and the constraints specified in the sections - above.</t> - - <t>The benchmarking network topology will be an independent test setup - and MUST NOT be connected to devices that may forward the test traffic - into a production network, or misroute traffic to the test management - network.</t> - - <t>Further, benchmarking is performed on a "black-box" basis, relying - solely on measurements observable external to the DUT/SUT.</t> - - <t>Special capabilities SHOULD NOT exist in the DUT/SUT specifically for - benchmarking purposes. Any implications for network security arising - from the DUT/SUT SHOULD be identical in the lab and in production - networks.</t> - </section> - - <section anchor="IANA" title="IANA Considerations"> - <t>No IANA Action is requested at this time.</t> - </section> - - <section title="Acknowledgements"> - <t>The authors appreciate and acknowledge comments from Scott Bradner, - Marius Georgescu, Ramki Krishnan, Doug Montgomery, Martin Klozik, - Christian Trautman, and others for their reviews.</t> - </section> - </middle> - - <back> - <references title="Normative References"> - <?rfc ?> - - <?rfc include="reference.RFC.2119"?> - - <?rfc ?> - - <?rfc include="reference.RFC.2330"?> - - <?rfc include='reference.RFC.2544'?> - - <?rfc include="reference.RFC.2679"?> - - <?rfc include='reference.RFC.2680'?> - - <?rfc include='reference.RFC.3393'?> - - <?rfc include='reference.RFC.3432'?> - - <?rfc include='reference.RFC.2681'?> - - <?rfc include='reference.RFC.5905'?> - - <?rfc include='reference.RFC.4689'?> - - <?rfc include='reference.RFC.4737'?> - - <?rfc include='reference.RFC.5357'?> - - <?rfc include='reference.RFC.2889'?> - - <?rfc include='reference.RFC.3918'?> - - <?rfc include='reference.RFC.6201'?> - - <?rfc include='reference.RFC.2285'?> - - <reference anchor="NFV.PER001"> - <front> - <title>Network Function Virtualization: Performance and Portability - Best Practices</title> - - <author fullname="ETSI NFV" initials="" surname=""> - <organization/> - </author> - - <date month="June" year="2014"/> - </front> - - <seriesInfo name="Group Specification" - value="ETSI GS NFV-PER 001 V1.1.1 (2014-06)"/> - - <format type="PDF"/> - </reference> - </references> - - <references title="Informative References"> - <?rfc include='reference.RFC.1242'?> - - <?rfc include='reference.RFC.5481'?> - - <?rfc include='reference.RFC.6049'?> - - <?rfc include='reference.RFC.6248'?> - - <?rfc include='reference.RFC.6390'?> - - <?rfc include='reference.I-D.ietf-bmwg-virtual-net'?> - - <?rfc include='reference.I-D.huang-bmwg-virtual-network-performance'?> - - <reference anchor="TestTopo"> - <front> - <title>Test Topologies - https://wiki.opnfv.org/vsperf/test_methodology</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="LTDoverV"> - <front> - <title>LTD Test Spec Overview - https://wiki.opnfv.org/wiki/vswitchperf_test_spec_review</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="LTD"> - <front> - <title>LTD Test Specification - http://artifacts.opnfv.org/vswitchperf/docs/requirements/index.html</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="BrahRel"> - <front> - <title>Brahmaputra, Second OPNFV Release - https://www.opnfv.org/brahmaputra</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="IFA003"> - <front> - <title>https://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA003_Acceleration_-_vSwitch_Spec/</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - </references> - </back> -</rfc> diff --git a/docs/testing/developer/devguide/requirements/ietf_draft/draft-ietf-bmwg-vswitch-opnfv-01.xml b/docs/testing/developer/devguide/requirements/ietf_draft/draft-ietf-bmwg-vswitch-opnfv-01.xml deleted file mode 100644 index c8a3d99b..00000000 --- a/docs/testing/developer/devguide/requirements/ietf_draft/draft-ietf-bmwg-vswitch-opnfv-01.xml +++ /dev/null @@ -1,1027 +0,0 @@ -<?xml version="1.0" encoding="US-ASCII"?> -<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -<?rfc toc="yes"?> -<?rfc tocompact="yes"?> -<?rfc tocdepth="3"?> -<?rfc tocindent="yes"?> -<?rfc symrefs="yes"?> -<?rfc sortrefs="yes"?> -<?rfc comments="yes"?> -<?rfc inline="yes"?> -<?rfc compact="yes"?> -<?rfc subcompact="no"?> -<rfc category="info" docName="draft-ietf-bmwg-vswitch-opnfv-01" - ipr="trust200902"> - <front> - <title abbrev="Benchmarking vSwitches">Benchmarking Virtual Switches in - OPNFV</title> - - <author fullname="Maryam Tahhan" initials="M." surname="Tahhan"> - <organization>Intel</organization> - - <address> - <postal> - <street/> - - <city/> - - <region/> - - <code/> - - <country/> - </postal> - - <phone/> - - <facsimile/> - - <email>maryam.tahhan@intel.com</email> - - <uri/> - </address> - </author> - - <author fullname="Billy O'Mahony" initials="B." surname="O'Mahony"> - <organization>Intel</organization> - - <address> - <postal> - <street/> - - <city/> - - <region/> - - <code/> - - <country/> - </postal> - - <phone/> - - <facsimile/> - - <email>billy.o.mahony@intel.com</email> - - <uri/> - </address> - </author> - - <author fullname="Al Morton" initials="A." surname="Morton"> - <organization>AT&T Labs</organization> - - <address> - <postal> - <street>200 Laurel Avenue South</street> - - <city>Middletown,</city> - - <region>NJ</region> - - <code>07748</code> - - <country>USA</country> - </postal> - - <phone>+1 732 420 1571</phone> - - <facsimile>+1 732 368 1192</facsimile> - - <email>acmorton@att.com</email> - - <uri>http://home.comcast.net/~acmacm/</uri> - </address> - </author> - - <date day="10" month="October" year="2016"/> - - <abstract> - <t>This memo describes the progress of the Open Platform for NFV (OPNFV) - project on virtual switch performance "VSWITCHPERF". This project - intends to build on the current and completed work of the Benchmarking - Methodology Working Group in IETF, by referencing existing literature. - The Benchmarking Methodology Working Group has traditionally conducted - laboratory characterization of dedicated physical implementations of - internetworking functions. Therefore, this memo begins to describe the - additional considerations when virtual switches are implemented in - general-purpose hardware. The expanded tests and benchmarks are also - influenced by the OPNFV mission to support virtualization of the "telco" - infrastructure.</t> - </abstract> - - <note title="Requirements Language"> - <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in <xref - target="RFC2119">RFC 2119</xref>.</t> - - <t/> - </note> - </front> - - <middle> - <section title="Introduction"> - <t>Benchmarking Methodology Working Group (BMWG) has traditionally - conducted laboratory characterization of dedicated physical - implementations of internetworking functions. The Black-box Benchmarks - of Throughput, Latency, Forwarding Rates and others have served our - industry for many years. Now, Network Function Virtualization (NFV) has - the goal to transform how internetwork functions are implemented, and - therefore has garnered much attention.</t> - - <t>This memo summarizes the progress of the Open Platform for NFV - (OPNFV) project on virtual switch performance characterization, - "VSWITCHPERF", through the Brahmaputra (second) release <xref - target="BrahRel"/>. This project intends to build on the current and - completed work of the Benchmarking Methodology Working Group in IETF, by - referencing existing literature. For example, currently the most often - referenced RFC is <xref target="RFC2544"/> (which depends on <xref - target="RFC1242"/>) and foundation of the benchmarking work in OPNFV is - common and strong.</t> - - <t>See - https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases - for more background, and the OPNFV website for general information: - https://www.opnfv.org/</t> - - <t>The authors note that OPNFV distinguishes itself from other open - source compute and networking projects through its emphasis on existing - "telco" services as opposed to cloud-computing. There are many ways in - which telco requirements have different emphasis on performance - dimensions when compared to cloud computing: support for and transfer of - isochronous media streams is one example.</t> - - <t>Note also that the move to NFV Infrastructure has resulted in many - new benchmarking initiatives across the industry. The authors are - currently doing their best to maintain alignment with many other - projects, and this Internet Draft is one part of the efforts. We - acknowledge the early work in <xref - target="I-D.huang-bmwg-virtual-network-performance"/>, and useful - discussion with the authors.</t> - </section> - - <section title="Scope"> - <t>The primary purpose and scope of the memo is to inform the industry - of work-in-progress that builds on the body of extensive BMWG literature - and experience, and describe the extensions needed for benchmarking - virtual switches. Inital feedback indicates that many of these - extensions may be applicable beyond the current scope (to hardware - switches in the NFV Infrastructure and to virtual routers, for example). - Additionally, this memo serves as a vehicle to include more detail and - commentary from BMWG and other Open Source communities, under BMWG's - chartered work to characterize the NFV Infrastructure (a virtual switch - is an important aspect of that infrastructure).</t> - - <t>The benchmarking covered in this memo should be applicable to many - types of vswitches, and remain vswitch-agnostic to great degree. There - has been no attempt to track and test all features of any specific - vswitch implementation.</t> - </section> - - <section title="Benchmarking Considerations"> - <t>This section highlights some specific considerations (from <xref - target="I-D.ietf-bmwg-virtual-net"/>)related to Benchmarks for virtual - switches. The OPNFV project is sharing its present view on these areas, - as they develop their specifications in the Level Test Design (LTD) - document.</t> - - <section title="Comparison with Physical Network Functions"> - <t>To compare the performance of virtual designs and implementations - with their physical counterparts, identical benchmarks are needed. - BMWG has developed specifications for many network functions this memo - re-uses existing benchmarks through references, and expands them - during development of new methods. A key configuration aspect is the - number of parallel cores required to achieve comparable performance - with a given physical device, or whether some limit of scale was - reached before the cores could achieve the comparable level.</t> - - <t>It's unlikely that the virtual switch will be the only application - running on the SUT, so CPU utilization, Cache utilization, and Memory - footprint should also be recorded for the virtual implementations of - internetworking functions.</t> - </section> - - <section title="Continued Emphasis on Black-Box Benchmarks"> - <t>External observations remain essential as the basis for Benchmarks. - Internal observations with fixed specification and interpretation will - be provided in parallel to assist the development of operations - procedures when the technology is deployed.</t> - </section> - - <section title="New Configuration Parameters"> - <t>A key consideration when conducting any sort of benchmark is trying - to ensure the consistency and repeatability of test results. When - benchmarking the performance of a vSwitch there are many factors that - can affect the consistency of results, one key factor is matching the - various hardware and software details of the SUT. This section lists - some of the many new parameters which this project believes are - critical to report in order to achieve repeatability.</t> - - <t>Hardware details including:</t> - - <t><list style="symbols"> - <t>Platform details</t> - - <t>Processor details</t> - - <t>Memory information (type and size)</t> - - <t>Number of enabled cores</t> - - <t>Number of cores used for the test</t> - - <t>Number of physical NICs, as well as their details - (manufacturer, versions, type and the PCI slot they are plugged - into)</t> - - <t>NIC interrupt configuration</t> - - <t>BIOS version, release date and any configurations that were - modified</t> - - <t>CPU microcode level</t> - - <t>Memory DIMM configurations (quad rank performance may not be - the same as dual rank) in size, freq and slot locations</t> - - <t>PCI configuration parameters (payload size, early ack - option...)</t> - - <t>Power management at all levels (ACPI sleep states, processor - package, OS...)</t> - </list>Software details including:</t> - - <t><list style="symbols"> - <t>OS parameters and behavior (text vs graphical no one typing at - the console on one system)</t> - - <t>OS version (for host and VNF)</t> - - <t>Kernel version (for host and VNF)</t> - - <t>GRUB boot parameters (for host and VNF)</t> - - <t>Hypervisor details (Type and version)</t> - - <t>Selected vSwitch, version number or commit id used</t> - - <t>vSwitch launch command line if it has been parameterised</t> - - <t>Memory allocation to the vSwitch</t> - - <t>which NUMA node it is using, and how many memory channels</t> - - <t>DPDK or any other SW dependency version number or commit id - used</t> - - <t>Memory allocation to a VM - if it's from Hugpages/elsewhere</t> - - <t>VM storage type: snapshot/independent persistent/independent - non-persistent</t> - - <t>Number of VMs</t> - - <t>Number of Virtual NICs (vNICs), versions, type and driver</t> - - <t>Number of virtual CPUs and their core affinity on the host</t> - - <t>Number vNIC interrupt configuration</t> - - <t>Thread affinitization for the applications (including the - vSwitch itself) on the host</t> - - <t>Details of Resource isolation, such as CPUs designated for - Host/Kernel (isolcpu) and CPUs designated for specific processes - (taskset). - Test duration. - Number of flows.</t> - </list></t> - - <t>Test Traffic Information:<list style="symbols"> - <t>Traffic type - UDP, TCP, IMIX / Other</t> - - <t>Packet Sizes</t> - - <t>Deployment Scenario</t> - </list></t> - - <t/> - </section> - - <section title="Flow classification"> - <t>Virtual switches group packets into flows by processing and - matching particular packet or frame header information, or by matching - packets based on the input ports. Thus a flow can be thought of a - sequence of packets that have the same set of header field values - (5-tuple) or have arrived on the same port. Performance results can - vary based on the parameters the vSwitch uses to match for a flow. The - recommended flow classification parameters for any vSwitch performance - tests are: the input port, the source IP address, the destination IP - address and the Ethernet protocol type field. It is essential to - increase the flow timeout time on a vSwitch before conducting any - performance tests that do not measure the flow setup time. Normally - the first packet of a particular stream will install the flow in the - virtual switch which adds an additional latency, subsequent packets of - the same flow are not subject to this latency if the flow is already - installed on the vSwitch.</t> - </section> - - <section title="Benchmarks using Baselines with Resource Isolation"> - <t>This outline describes measurement of baseline with isolated - resources at a high level, which is the intended approach at this - time.</t> - - <t><list style="numbers"> - <t>Baselines: <list style="symbols"> - <t>Optional: Benchmark platform forwarding capability without - a vswitch or VNF for at least 72 hours (serves as a means of - platform validation and a means to obtain the base performance - for the platform in terms of its maximum forwarding rate and - latency). <figure> - <preamble>Benchmark platform forwarding - capability</preamble> - - <artwork align="right"><![CDATA[ __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | Simple Forwarding App | | Host - | | | | | - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - - <postamble/> - </figure></t> - - <t>Benchmark VNF forwarding capability with direct - connectivity (vSwitch bypass, e.g., SR/IOV) for at least 72 - hours (serves as a means of VNF validation and a means to - obtain the base performance for the VNF in terms of its - maximum forwarding rate and latency). The metrics gathered - from this test will serve as a key comparison point for - vSwitch bypass technologies performance and vSwitch - performance. <figure align="right"> - <preamble>Benchmark VNF forwarding capability</preamble> - - <artwork><![CDATA[ __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | VNF | | | - | | | | | - | +------------------------------------------+ | | - | | Passthrough/SR-IOV | | Host - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - - <postamble/> - </figure></t> - - <t>Benchmarking with isolated resources alone, with other - resources (both HW&SW) disabled Example, vSw and VM are - SUT</t> - - <t>Benchmarking with isolated resources alone, leaving some - resources unused</t> - - <t>Benchmark with isolated resources and all resources - occupied</t> - </list></t> - - <t>Next Steps<list style="symbols"> - <t>Limited sharing</t> - - <t>Production scenarios</t> - - <t>Stressful scenarios</t> - </list></t> - </list></t> - </section> - </section> - - <section title="VSWITCHPERF Specification Summary"> - <t>The overall specification in preparation is referred to as a Level - Test Design (LTD) document, which will contain a suite of performance - tests. The base performance tests in the LTD are based on the - pre-existing specifications developed by BMWG to test the performance of - physical switches. These specifications include:</t> - - <t><list style="symbols"> - <t><xref target="RFC2544"/> Benchmarking Methodology for Network - Interconnect Devices</t> - - <t><xref target="RFC2889"/> Benchmarking Methodology for LAN - Switching</t> - - <t><xref target="RFC6201"/> Device Reset Characterization</t> - - <t><xref target="RFC5481"/> Packet Delay Variation Applicability - Statement</t> - </list></t> - - <t>Some of the above/newer RFCs are being applied in benchmarking for - the first time, and represent a development challenge for test equipment - developers. Fortunately, many members of the testing system community - have engaged on the VSPERF project, including an open source test - system.</t> - - <t>In addition to this, the LTD also re-uses the terminology defined - by:</t> - - <t><list style="symbols"> - <t><xref target="RFC2285"/> Benchmarking Terminology for LAN - Switching Devices</t> - - <t><xref target="RFC5481"/> Packet Delay Variation Applicability - Statement</t> - </list></t> - - <t/> - - <t>Specifications to be included in future updates of the LTD - include:<list style="symbols"> - <t><xref target="RFC3918"/> Methodology for IP Multicast - Benchmarking</t> - - <t><xref target="RFC4737"/> Packet Reordering Metrics</t> - </list></t> - - <t>As one might expect, the most fundamental internetworking - characteristics of Throughput and Latency remain important when the - switch is virtualized, and these benchmarks figure prominently in the - specification.</t> - - <t>When considering characteristics important to "telco" network - functions, we must begin to consider additional performance metrics. In - this case, the project specifications have referenced metrics from the - IETF IP Performance Metrics (IPPM) literature. This means that the <xref - target="RFC2544"/> test of Latency is replaced by measurement of a - metric derived from IPPM's <xref target="RFC2679"/>, where a set of - statistical summaries will be provided (mean, max, min, etc.). Further - metrics planned to be benchmarked include packet delay variation as - defined by <xref target="RFC5481"/> , reordering, burst behaviour, DUT - availability, DUT capacity and packet loss in long term testing at - Throughput level, where some low-level of background loss may be present - and characterized.</t> - - <t>Tests have been (or will be) designed to collect the metrics - below:</t> - - <t><list style="symbols"> - <t>Throughput Tests to measure the maximum forwarding rate (in - frames per second or fps) and bit rate (in Mbps) for a constant load - (as defined by <xref target="RFC1242"/>) without traffic loss.</t> - - <t>Packet and Frame Delay Distribution Tests to measure average, min - and max packet and frame delay for constant loads.</t> - - <t>Packet Delay Tests to understand latency distribution for - different packet sizes and over an extended test run to uncover - outliers.</t> - - <t>Scalability Tests to understand how the virtual switch performs - as the number of flows, active ports, complexity of the forwarding - logic’s configuration… it has to deal with - increases.</t> - - <t>Stream Performance Tests (TCP, UDP) to measure bulk data transfer - performance, i.e. how fast systems can send and receive data through - the switch.</t> - - <t>Control Path and Datapath Coupling Tests, to understand how - closely coupled the datapath and the control path are as well as the - effect of this coupling on the performance of the DUT (example: - delay of the initial packet of a flow).</t> - - <t>CPU and Memory Consumption Tests to understand the virtual - switch’s footprint on the system, usually conducted as - auxiliary measurements with benchmarks above. They include: CPU - utilization, Cache utilization and Memory footprint.</t> - - <t>The so-called "Soak" tests, where the selected test is conducted - over a long period of time (with an ideal duration of 24 hours, but - only long enough to determine that stability issues exist when - found; there is no requirement to continue a test when a DUT - exhibits instability over time). The key performance characteristics - and benchmarks for a DUT are determined (using short duration tests) - prior to conducting soak tests. The purpose of soak tests is to - capture transient changes in performance which may occur due to - infrequent processes, memory leaks, or the low probability - coincidence of two or more processes. The stability of the DUT is - the paramount consideration, so performance must be evaluated - periodically during continuous testing, and this results in use of - <xref target="RFC2889"/> Frame Rate metrics instead of <xref - target="RFC2544"/> Throughput (which requires stopping traffic to - allow time for all traffic to exit internal queues), for - example.</t> - </list></t> - - <t>Future/planned test specs include:<list style="symbols"> - <t>Request/Response Performance Tests (TCP, UDP) which measure the - transaction rate through the switch.</t> - - <t>Noisy Neighbour Tests, to understand the effects of resource - sharing on the performance of a virtual switch.</t> - - <t>Tests derived from examination of ETSI NFV Draft GS IFA003 - requirements <xref target="IFA003"/> on characterization of - acceleration technologies applied to vswitches.</t> - </list>The flexibility of deployment of a virtual switch within a - network means that the BMWG IETF existing literature needs to be used to - characterize the performance of a switch in various deployment - scenarios. The deployment scenarios under consideration include:</t> - - <t><figure> - <preamble>Physical port to virtual switch to physical - port</preamble> - - <artwork><![CDATA[ __ - +--------------------------------------------------+ | - | +--------------------+ | | - | | | | | - | | v | | Host - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure></t> - - <t><figure> - <preamble>Physical port to virtual switch to VNF to virtual switch - to physical port</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ : | | - | | | | | Guest - | : v | | - | +---------------+ +---------------+ | | - | | logical port 0| | logical port 1| | | - +---+---------------+-----------+---------------+---+ __| - ^ : - | | - : v __ - +---+---------------+----------+---------------+---+ | - | | logical port 0| | logical port 1| | | - | +---------------+ +---------------+ | | - | ^ : | | - | | | | | Host - | : v | | - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>Physical port to virtual switch to VNF to virtual switch - to VNF to virtual switch to physical port</preamble> - - <artwork><![CDATA[ __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | ^ | | | ^ | | | - | | v | | | v | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 1 | | | | 0 1 | | | - +---+---------------+--+ +---+---------------+--+__| - ^ : ^ : - | | | | - : v : v _ - +---+---------------+---------+---------------+--+ | - | | 0 1 | | 3 4 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | ^ | ^ | | | Host - | | |-----------------| v | | - | +--------------+ +--------------+ | | - | | phy ports | vSwitch | phy ports | | | - +---+--------------+----------+--------------+---+_| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>Physical port to virtual switch to VNF</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ | | - | | | | Guest - | : | | - | +---------------+ | | - | | logical port 0| | | - +---+---------------+-------------------------------+ __| - ^ - | - : __ - +---+---------------+------------------------------+ | - | | logical port 0| | | - | +---------------+ | | - | ^ | | - | | | | Host - | : | | - | +--------------+ | | - | | phy port | vSwitch | | - +---+--------------+------------ -------------- ---+ __| - ^ - | - : - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>VNF to virtual switch to physical port</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | : | | - | | | | Guest - | v | | - | +---------------+ | | - | | logical port | | | - +-------------------------------+---------------+---+ __| - : - | - v __ - +------------------------------+---------------+---+ | - | | logical port | | | - | +---------------+ | | - | : | | - | | | | Host - | v | | - | +--------------+ | | - | vSwitch | phy port | | | - +-------------------------------+--------------+---+ __| - : - | - v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>VNF to virtual switch to VNF</preamble> - - <artwork><![CDATA[ __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | | | | ^ | | - | v | | | | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 | | | | 0 | | | - +---+---------------+--+ +---+---------------+--+__| - : ^ - | | - v : _ - +---+---------------+---------+---------------+--+ | - | | 1 | | 1 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | | ^ | | Host - | L-----------------+ | | - | | | - | vSwitch | | - +------------------------------------------------+_|]]></artwork> - </figure></t> - - <t>A set of Deployment Scenario figures is available on the VSPERF Test - Methodology Wiki page <xref target="TestTopo"/>.</t> - </section> - - <section title="3x3 Matrix Coverage"> - <t>This section organizes the many existing test specifications into the - "3x3" matrix (introduced in <xref target="I-D.ietf-bmwg-virtual-net"/>). - Because the LTD specification ID names are quite long, this section is - organized into lists for each occupied cell of the matrix (not all are - occupied, also the matrix has grown to 3x4 to accommodate scale metrics - when displaying the coverage of many metrics/benchmarks). The current - version of the LTD specification is available <xref target="LTD"/>.</t> - - <t>The tests listed below assess the activation of paths in the data - plane, rather than the control plane.</t> - - <t>A complete list of tests with short summaries is available on the - VSPERF "LTD Test Spec Overview" Wiki page <xref target="LTDoverV"/>.</t> - - <section title="Speed of Activation"> - <t><list style="symbols"> - <t>Activation.RFC2889.AddressLearningRate</t> - - <t>PacketLatency.InitialPacketProcessingLatency</t> - </list></t> - </section> - - <section title="Accuracy of Activation section"> - <t><list style="symbols"> - <t>CPDP.Coupling.Flow.Addition</t> - </list></t> - </section> - - <section title="Reliability of Activation"> - <t><list style="symbols"> - <t>Throughput.RFC2544.SystemRecoveryTime</t> - - <t>Throughput.RFC2544.ResetTime</t> - </list></t> - </section> - - <section title="Scale of Activation"> - <t><list style="symbols"> - <t>Activation.RFC2889.AddressCachingCapacity</t> - </list></t> - </section> - - <section title="Speed of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2544.PacketLossRate</t> - - <t>CPU.RFC2544.0PacketLoss</t> - - <t>Throughput.RFC2544.PacketLossRateFrameModification</t> - - <t>Throughput.RFC2544.BackToBackFrames</t> - - <t>Throughput.RFC2889.MaxForwardingRate</t> - - <t>Throughput.RFC2889.ForwardPressure</t> - - <t>Throughput.RFC2889.BroadcastFrameForwarding</t> - </list></t> - </section> - - <section title="Accuracy of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2889.ErrorFramesFiltering</t> - - <t>Throughput.RFC2544.Profile</t> - </list></t> - </section> - - <section title="Reliability of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2889.Soak</t> - - <t>Throughput.RFC2889.SoakFrameModification</t> - - <t>PacketDelayVariation.RFC3393.Soak</t> - </list></t> - </section> - - <section title="Scalability of Operation"> - <t><list style="symbols"> - <t>Scalability.RFC2544.0PacketLoss</t> - - <t>MemoryBandwidth.RFC2544.0PacketLoss.Scalability</t> - </list></t> - </section> - - <section title="Summary"> - <t><figure> - <artwork><![CDATA[|------------------------------------------------------------------------| -| | | | | | -| | SPEED | ACCURACY | RELIABILITY | SCALE | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Activation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Operation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| De-activation | | | | | -| | | | | | -|------------------------------------------------------------------------|]]></artwork> - </figure></t> - </section> - </section> - - <section title="Security Considerations"> - <t>Benchmarking activities as described in this memo are limited to - technology characterization of a Device Under Test/System Under Test - (DUT/SUT) using controlled stimuli in a laboratory environment, with - dedicated address space and the constraints specified in the sections - above.</t> - - <t>The benchmarking network topology will be an independent test setup - and MUST NOT be connected to devices that may forward the test traffic - into a production network, or misroute traffic to the test management - network.</t> - - <t>Further, benchmarking is performed on a "black-box" basis, relying - solely on measurements observable external to the DUT/SUT.</t> - - <t>Special capabilities SHOULD NOT exist in the DUT/SUT specifically for - benchmarking purposes. Any implications for network security arising - from the DUT/SUT SHOULD be identical in the lab and in production - networks.</t> - </section> - - <section anchor="IANA" title="IANA Considerations"> - <t>No IANA Action is requested at this time.</t> - </section> - - <section title="Acknowledgements"> - <t>The authors appreciate and acknowledge comments from Scott Bradner, - Marius Georgescu, Ramki Krishnan, Doug Montgomery, Martin Klozik, - Christian Trautman, and others for their reviews.</t> - </section> - </middle> - - <back> - <references title="Normative References"> - <?rfc ?> - - <?rfc include="reference.RFC.2119"?> - - <?rfc ?> - - <?rfc include="reference.RFC.2330"?> - - <?rfc include='reference.RFC.2544'?> - - <?rfc include="reference.RFC.2679"?> - - <?rfc include='reference.RFC.2680'?> - - <?rfc include='reference.RFC.3393'?> - - <?rfc include='reference.RFC.3432'?> - - <?rfc include='reference.RFC.2681'?> - - <?rfc include='reference.RFC.5905'?> - - <?rfc include='reference.RFC.4689'?> - - <?rfc include='reference.RFC.4737'?> - - <?rfc include='reference.RFC.5357'?> - - <?rfc include='reference.RFC.2889'?> - - <?rfc include='reference.RFC.3918'?> - - <?rfc include='reference.RFC.6201'?> - - <?rfc include='reference.RFC.2285'?> - - <reference anchor="NFV.PER001"> - <front> - <title>Network Function Virtualization: Performance and Portability - Best Practices</title> - - <author fullname="ETSI NFV" initials="" surname=""> - <organization/> - </author> - - <date month="June" year="2014"/> - </front> - - <seriesInfo name="Group Specification" - value="ETSI GS NFV-PER 001 V1.1.1 (2014-06)"/> - - <format type="PDF"/> - </reference> - </references> - - <references title="Informative References"> - <?rfc include='reference.RFC.1242'?> - - <?rfc include='reference.RFC.5481'?> - - <?rfc include='reference.RFC.6049'?> - - <?rfc include='reference.RFC.6248'?> - - <?rfc include='reference.RFC.6390'?> - - <?rfc include='reference.I-D.ietf-bmwg-virtual-net'?> - - <?rfc include='reference.I-D.huang-bmwg-virtual-network-performance'?> - - <reference anchor="TestTopo"> - <front> - <title>Test Topologies - https://wiki.opnfv.org/vsperf/test_methodology</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="LTDoverV"> - <front> - <title>LTD Test Spec Overview - https://wiki.opnfv.org/wiki/vswitchperf_test_spec_review</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="LTD"> - <front> - <title>LTD Test Specification - http://artifacts.opnfv.org/vswitchperf/brahmaputra/docs/requirements/index.html</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="BrahRel"> - <front> - <title>Brahmaputra, Second OPNFV Release - https://www.opnfv.org/brahmaputra</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="IFA003"> - <front> - <title>https://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA003_Acceleration_-_vSwitch_Spec/</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - </references> - </back> -</rfc> diff --git a/docs/testing/developer/devguide/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-00.xml b/docs/testing/developer/devguide/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-00.xml deleted file mode 100644 index b5f7f833..00000000 --- a/docs/testing/developer/devguide/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-00.xml +++ /dev/null @@ -1,964 +0,0 @@ -<?xml version="1.0" encoding="US-ASCII"?> -<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -<?rfc toc="yes"?> -<?rfc tocompact="yes"?> -<?rfc tocdepth="3"?> -<?rfc tocindent="yes"?> -<?rfc symrefs="yes"?> -<?rfc sortrefs="yes"?> -<?rfc comments="yes"?> -<?rfc inline="yes"?> -<?rfc compact="yes"?> -<?rfc subcompact="no"?> -<rfc category="info" docName="draft-vsperf-bmwg-vswitch-opnfv-01" - ipr="trust200902"> - <front> - <title abbrev="Benchmarking vSwitches">Benchmarking Virtual Switches in - OPNFV</title> - - <author fullname="Maryam Tahhan" initials="M." surname="Tahhan"> - <organization>Intel</organization> - - <address> - <postal> - <street/> - - <city/> - - <region/> - - <code/> - - <country/> - </postal> - - <phone/> - - <facsimile/> - - <email>maryam.tahhan@intel.com</email> - - <uri/> - </address> - </author> - - <author fullname="Billy O'Mahony" initials="B." surname="O'Mahony"> - <organization>Intel</organization> - - <address> - <postal> - <street/> - - <city/> - - <region/> - - <code/> - - <country/> - </postal> - - <phone/> - - <facsimile/> - - <email>billy.o.mahony@intel.com</email> - - <uri/> - </address> - </author> - - <author fullname="Al Morton" initials="A." surname="Morton"> - <organization>AT&T Labs</organization> - - <address> - <postal> - <street>200 Laurel Avenue South</street> - - <city>Middletown,</city> - - <region>NJ</region> - - <code>07748</code> - - <country>USA</country> - </postal> - - <phone>+1 732 420 1571</phone> - - <facsimile>+1 732 368 1192</facsimile> - - <email>acmorton@att.com</email> - - <uri>http://home.comcast.net/~acmacm/</uri> - </address> - </author> - - <date day="14" month="October" year="2015"/> - - <abstract> - <t>This memo describes the progress of the Open Platform for NFV (OPNFV) - project on virtual switch performance "VSWITCHPERF". This project - intends to build on the current and completed work of the Benchmarking - Methodology Working Group in IETF, by referencing existing literature. - The Benchmarking Methodology Working Group has traditionally conducted - laboratory characterization of dedicated physical implementations of - internetworking functions. Therefore, this memo begins to describe the - additional considerations when virtual switches are implemented in - general-purpose hardware. The expanded tests and benchmarks are also - influenced by the OPNFV mission to support virtualization of the "telco" - infrastructure.</t> - </abstract> - - <note title="Requirements Language"> - <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in <xref - target="RFC2119">RFC 2119</xref>.</t> - - <t/> - </note> - </front> - - <middle> - <section title="Introduction"> - <t>Benchmarking Methodology Working Group (BMWG) has traditionally - conducted laboratory characterization of dedicated physical - implementations of internetworking functions. The Black-box Benchmarks - of Throughput, Latency, Forwarding Rates and others have served our - industry for many years. Now, Network Function Virtualization (NFV) has - the goal to transform how internetwork functions are implemented, and - therefore has garnered much attention.</t> - - <t>This memo describes the progress of the Open Platform for NFV (OPNFV) - project on virtual switch performance characterization, "VSWITCHPERF". - This project intends to build on the current and completed work of the - Benchmarking Methodology Working Group in IETF, by referencing existing - literature. For example, currently the most often referenced RFC is - <xref target="RFC2544"/> (which depends on <xref target="RFC1242"/>) and - foundation of the benchmarking work in OPNFV is common and strong.</t> - - <t>See - https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases - for more background, and the OPNFV website for general information: - https://www.opnfv.org/</t> - - <t>The authors note that OPNFV distinguishes itself from other open - source compute and networking projects through its emphasis on existing - "telco" services as opposed to cloud-computing. There are many ways in - which telco requirements have different emphasis on performance - dimensions when compared to cloud computing: support for and transfer of - isochronous media streams is one example.</t> - - <t>Note also that the move to NFV Infrastructure has resulted in many - new benchmarking initiatives across the industry, and the authors are - currently doing their best to maintain alignment with many other - projects, and this Internet Draft is evidence of the efforts.</t> - </section> - - <section title="Scope"> - <t>The primary purpose and scope of the memo is to inform BMWG of - work-in-progress that builds on the body of extensive literature and - experience. Additionally, once the initial information conveyed here is - received, this memo may be expanded to include more detail and - commentary from both BMWG and OPNFV communities, under BMWG's chartered - work to characterize the NFV Infrastructure (a virtual switch is an - important aspect of that infrastructure).</t> - </section> - - <section title="Benchmarking Considerations"> - <t>This section highlights some specific considerations (from <xref - target="I-D.ietf-bmwg-virtual-net"/>)related to Benchmarks for virtual - switches. The OPNFV project is sharing its present view on these areas, - as they develop their specifications in the Level Test Design (LTD) - document.</t> - - <section title="Comparison with Physical Network Functions"> - <t>To compare the performance of virtual designs and implementations - with their physical counterparts, identical benchmarks are needed. - BMWG has developed specifications for many network functions this memo - re-uses existing benchmarks through references, and expands them - during development of new methods. A key configuration aspect is the - number of parallel cores required to achieve comparable performance - with a given physical device, or whether some limit of scale was - reached before the cores could achieve the comparable level.</t> - - <t>It's unlikely that the virtual switch will be the only application - running on the SUT, so CPU utilization, Cache utilization, and Memory - footprint should also be recorded for the virtual implementations of - internetworking functions.</t> - </section> - - <section title="Continued Emphasis on Black-Box Benchmarks"> - <t>External observations remain essential as the basis for Benchmarks. - Internal observations with fixed specification and interpretation will - be provided in parallel to assist the development of operations - procedures when the technology is deployed.</t> - </section> - - <section title="New Configuration Parameters"> - <t>A key consideration when conducting any sort of benchmark is trying - to ensure the consistency and repeatability of test results. When - benchmarking the performance of a vSwitch there are many factors that - can affect the consistency of results, one key factor is matching the - various hardware and software details of the SUT. This section lists - some of the many new parameters which this project believes are - critical to report in order to achieve repeatability.</t> - - <t>Hardware details including:</t> - - <t><list style="symbols"> - <t>Platform details</t> - - <t>Processor details</t> - - <t>Memory information (type and size)</t> - - <t>Number of enabled cores</t> - - <t>Number of cores used for the test</t> - - <t>Number of physical NICs, as well as their details - (manufacturer, versions, type and the PCI slot they are plugged - into)</t> - - <t>NIC interrupt configuration</t> - - <t>BIOS version, release date and any configurations that were - modified</t> - - <t>CPU microcode level</t> - - <t>Memory DIMM configurations (quad rank performance may not be - the same as dual rank) in size, freq and slot locations</t> - - <t>PCI configuration parameters (payload size, early ack - option...)</t> - - <t>Power management at all levels (ACPI sleep states, processor - package, OS...)</t> - </list>Software details including:</t> - - <t><list style="symbols"> - <t>OS parameters and behavior (text vs graphical no one typing at - the console on one system)</t> - - <t>OS version (for host and VNF)</t> - - <t>Kernel version (for host and VNF)</t> - - <t>GRUB boot parameters (for host and VNF)</t> - - <t>Hypervisor details (Type and version)</t> - - <t>Selected vSwitch, version number or commit id used</t> - - <t>vSwitch launch command line if it has been parameterised</t> - - <t>Memory allocation to the vSwitch</t> - - <t>which NUMA node it is using, and how many memory channels</t> - - <t>DPDK or any other SW dependency version number or commit id - used</t> - - <t>Memory allocation to a VM - if it's from Hugpages/elsewhere</t> - - <t>VM storage type: snapshot/independent persistent/independent - non-persistent</t> - - <t>Number of VMs</t> - - <t>Number of Virtual NICs (vNICs), versions, type and driver</t> - - <t>Number of virtual CPUs and their core affinity on the host</t> - - <t>Number vNIC interrupt configuration</t> - - <t>Thread affinitization for the applications (including the - vSwitch itself) on the host</t> - - <t>Details of Resource isolation, such as CPUs designated for - Host/Kernel (isolcpu) and CPUs designated for specific processes - (taskset). - Test duration. - Number of flows.</t> - </list></t> - - <t>Test Traffic Information:<list style="symbols"> - <t>Traffic type - UDP, TCP, IMIX / Other</t> - - <t>Packet Sizes</t> - - <t>Deployment Scenario</t> - </list></t> - - <t/> - </section> - - <section title="Flow classification"> - <t>Virtual switches group packets into flows by processing and - matching particular packet or frame header information, or by matching - packets based on the input ports. Thus a flow can be thought of a - sequence of packets that have the same set of header field values or - have arrived on the same port. Performance results can vary based on - the parameters the vSwitch uses to match for a flow. The recommended - flow classification parameters for any vSwitch performance tests are: - the input port, the source IP address, the destination IP address and - the Ethernet protocol type field. It is essential to increase the flow - timeout time on a vSwitch before conducting any performance tests that - do not measure the flow setup time. Normally the first packet of a - particular stream will install the flow in the virtual switch which - adds an additional latency, subsequent packets of the same flow are - not subject to this latency if the flow is already installed on the - vSwitch.</t> - </section> - - <section title="Benchmarks using Baselines with Resource Isolation"> - <t>This outline describes measurement of baseline with isolated - resources at a high level, which is the intended approach at this - time.</t> - - <t><list style="numbers"> - <t>Baselines: <list style="symbols"> - <t>Optional: Benchmark platform forwarding capability without - a vswitch or VNF for at least 72 hours (serves as a means of - platform validation and a means to obtain the base performance - for the platform in terms of its maximum forwarding rate and - latency). <figure> - <preamble>Benchmark platform forwarding - capability</preamble> - - <artwork align="right"><![CDATA[ __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | Simple Forwarding App | | Host - | | | | | - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - - <postamble/> - </figure></t> - - <t>Benchmark VNF forwarding capability with direct - connectivity (vSwitch bypass, e.g., SR/IOV) for at least 72 - hours (serves as a means of VNF validation and a means to - obtain the base performance for the VNF in terms of its - maximum forwarding rate and latency). The metrics gathered - from this test will serve as a key comparison point for - vSwitch bypass technologies performance and vSwitch - performance. <figure align="right"> - <preamble>Benchmark VNF forwarding capability</preamble> - - <artwork><![CDATA[ __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | VNF | | | - | | | | | - | +------------------------------------------+ | | - | | Passthrough/SR-IOV | | Host - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - - <postamble/> - </figure></t> - - <t>Benchmarking with isolated resources alone, with other - resources (both HW&SW) disabled Example, vSw and VM are - SUT</t> - - <t>Benchmarking with isolated resources alone, leaving some - resources unused</t> - - <t>Benchmark with isolated resources and all resources - occupied</t> - </list></t> - - <t>Next Steps<list style="symbols"> - <t>Limited sharing</t> - - <t>Production scenarios</t> - - <t>Stressful scenarios</t> - </list></t> - </list></t> - </section> - </section> - - <section title="VSWITCHPERF Specification Summary"> - <t>The overall specification in preparation is referred to as a Level - Test Design (LTD) document, which will contain a suite of performance - tests. The base performance tests in the LTD are based on the - pre-existing specifications developed by BMWG to test the performance of - physical switches. These specifications include:</t> - - <t><list style="symbols"> - <t><xref target="RFC2544"/> Benchmarking Methodology for Network - Interconnect Devices</t> - - <t><xref target="RFC2889"/> Benchmarking Methodology for LAN - Switching</t> - - <t><xref target="RFC6201"/> Device Reset Characterization</t> - - <t><xref target="RFC5481"/> Packet Delay Variation Applicability - Statement</t> - </list></t> - - <t>Some of the above/newer RFCs are being applied in benchmarking for - the first time, and represent a development challenge for test equipment - developers. Fortunately, many members of the testing system community - have engaged on the VSPERF project, including an open source test - system.</t> - - <t>In addition to this, the LTD also re-uses the terminology defined - by:</t> - - <t><list style="symbols"> - <t><xref target="RFC2285"/> Benchmarking Terminology for LAN - Switching Devices</t> - - <t><xref target="RFC5481"/> Packet Delay Variation Applicability - Statement</t> - </list></t> - - <t/> - - <t>Specifications to be included in future updates of the LTD - include:<list style="symbols"> - <t><xref target="RFC3918"/> Methodology for IP Multicast - Benchmarking</t> - - <t><xref target="RFC4737"/> Packet Reordering Metrics</t> - </list></t> - - <t>As one might expect, the most fundamental internetworking - characteristics of Throughput and Latency remain important when the - switch is virtualized, and these benchmarks figure prominently in the - specification.</t> - - <t>When considering characteristics important to "telco" network - functions, we must begin to consider additional performance metrics. In - this case, the project specifications have referenced metrics from the - IETF IP Performance Metrics (IPPM) literature. This means that the <xref - target="RFC2544"/> test of Latency is replaced by measurement of a - metric derived from IPPM's <xref target="RFC2679"/>, where a set of - statistical summaries will be provided (mean, max, min, etc.). Further - metrics planned to be benchmarked include packet delay variation as - defined by <xref target="RFC5481"/> , reordering, burst behaviour, DUT - availability, DUT capacity and packet loss in long term testing at - Throughput level, where some low-level of background loss may be present - and characterized.</t> - - <t>Tests have been (or will be) designed to collect the metrics - below:</t> - - <t><list style="symbols"> - <t>Throughput Tests to measure the maximum forwarding rate (in - frames per second or fps) and bit rate (in Mbps) for a constant load - (as defined by RFC1242) without traffic loss.</t> - - <t>Packet and Frame Delay Distribution Tests to measure average, min - and max packet and frame delay for constant loads.</t> - - <t>Packet Delay Tests to understand latency distribution for - different packet sizes and over an extended test run to uncover - outliers.</t> - - <t>Scalability Tests to understand how the virtual switch performs - as the number of flows, active ports, complexity of the forwarding - logic’s configuration… it has to deal with - increases.</t> - - <t>Stream Performance Tests (TCP, UDP) to measure bulk data transfer - performance, i.e. how fast systems can send and receive data through - the switch.</t> - - <t>Control Path and Datapath Coupling Tests, to understand how - closely coupled the datapath and the control path are as well as the - effect of this coupling on the performance of the DUT (example: - delay of the initial packet of a flow).</t> - - <t>CPU and Memory Consumption Tests to understand the virtual - switch’s footprint on the system, usually conducted as - auxiliary measurements with benchmarks above. They include: CPU - utilization, Cache utilization and Memory footprint.</t> - </list></t> - - <t>Future/planned test specs include:<list style="symbols"> - <t>Request/Response Performance Tests (TCP, UDP) which measure the - transaction rate through the switch.</t> - - <t>Noisy Neighbour Tests, to understand the effects of resource - sharing on the performance of a virtual switch.</t> - - <t>Tests derived from examination of ETSI NFV Draft GS IFA003 - requirements <xref target="IFA003"/> on characterization of - acceleration technologies applied to vswitches.</t> - </list>The flexibility of deployment of a virtual switch within a - network means that the BMWG IETF existing literature needs to be used to - characterize the performance of a switch in various deployment - scenarios. The deployment scenarios under consideration include:</t> - - <t><figure> - <preamble>Physical port to virtual switch to physical - port</preamble> - - <artwork><![CDATA[ __ - +--------------------------------------------------+ | - | +--------------------+ | | - | | | | | - | | v | | Host - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure></t> - - <t><figure> - <preamble>Physical port to virtual switch to VNF to virtual switch - to physical port</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ : | | - | | | | | Guest - | : v | | - | +---------------+ +---------------+ | | - | | logical port 0| | logical port 1| | | - +---+---------------+-----------+---------------+---+ __| - ^ : - | | - : v __ - +---+---------------+----------+---------------+---+ | - | | logical port 0| | logical port 1| | | - | +---------------+ +---------------+ | | - | ^ : | | - | | | | | Host - | : v | | - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>Physical port to virtual switch to VNF to virtual switch - to VNF to virtual switch to physical port</preamble> - - <artwork><![CDATA[ __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | ^ | | | ^ | | | - | | v | | | v | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 1 | | | | 0 1 | | | - +---+---------------+--+ +---+---------------+--+__| - ^ : ^ : - | | | | - : v : v _ - +---+---------------+---------+---------------+--+ | - | | 0 1 | | 3 4 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | ^ | ^ | | | Host - | | |-----------------| v | | - | +--------------+ +--------------+ | | - | | phy ports | vSwitch | phy ports | | | - +---+--------------+----------+--------------+---+_| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>Physical port to virtual switch to VNF</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ | | - | | | | Guest - | : | | - | +---------------+ | | - | | logical port 0| | | - +---+---------------+-------------------------------+ __| - ^ - | - : __ - +---+---------------+------------------------------+ | - | | logical port 0| | | - | +---------------+ | | - | ^ | | - | | | | Host - | : | | - | +--------------+ | | - | | phy port | vSwitch | | - +---+--------------+------------ -------------- ---+ __| - ^ - | - : - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>VNF to virtual switch to physical port</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | : | | - | | | | Guest - | v | | - | +---------------+ | | - | | logical port | | | - +-------------------------------+---------------+---+ __| - : - | - v __ - +------------------------------+---------------+---+ | - | | logical port | | | - | +---------------+ | | - | : | | - | | | | Host - | v | | - | +--------------+ | | - | vSwitch | phy port | | | - +-------------------------------+--------------+---+ __| - : - | - v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>VNF to virtual switch to VNF</preamble> - - <artwork><![CDATA[ __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | | | | ^ | | - | v | | | | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 | | | | 0 | | | - +---+---------------+--+ +---+---------------+--+__| - : ^ - | | - v : _ - +---+---------------+---------+---------------+--+ | - | | 1 | | 1 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | | ^ | | Host - | L-----------------+ | | - | | | - | vSwitch | | - +------------------------------------------------+_|]]></artwork> - </figure></t> - - <t>A set of Deployment Scenario figures is available on the VSPERF Test - Methodology Wiki page <xref target="TestTopo"/>. </t> - </section> - - <section title="3x3 Matrix Coverage"> - <t>This section organizes the many existing test specifications into the - "3x3" matrix (introduced in <xref target="I-D.ietf-bmwg-virtual-net"/>). - Because the LTD specification ID names are quite long, this section is - organized into lists for each occupied cell of the matrix (not all are - occupied, also the matrix has grown to 3x4 to accommodate scale metrics - when displaying the coverage of many metrics/benchmarks).</t> - - <t>The tests listed below assess the activation of paths in the data - plane, rather than the control plane.</t> - - <t>A complete list of tests with short summaries is available on the - VSPERF "LTD Test Spec Overview" Wiki page <xref target="LTDoverV"/>.</t> - - <section title="Speed of Activation"> - <t><list style="symbols"> - <t>Activation.RFC2889.AddressLearningRate</t> - - <t>PacketLatency.InitialPacketProcessingLatency</t> - </list></t> - </section> - - <section title="Accuracy of Activation section"> - <t><list style="symbols"> - <t>CPDP.Coupling.Flow.Addition</t> - </list></t> - </section> - - <section title="Reliability of Activation"> - <t><list style="symbols"> - <t>Throughput.RFC2544.SystemRecoveryTime</t> - - <t>Throughput.RFC2544.ResetTime</t> - </list></t> - </section> - - <section title="Scale of Activation"> - <t><list style="symbols"> - <t>Activation.RFC2889.AddressCachingCapacity</t> - </list></t> - </section> - - <section title="Speed of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2544.PacketLossRate</t> - - <t>CPU.RFC2544.0PacketLoss</t> - - <t>Throughput.RFC2544.PacketLossRateFrameModification</t> - - <t>Throughput.RFC2544.BackToBackFrames</t> - - <t>Throughput.RFC2889.MaxForwardingRate</t> - - <t>Throughput.RFC2889.ForwardPressure</t> - - <t>Throughput.RFC2889.BroadcastFrameForwarding</t> - </list></t> - </section> - - <section title="Accuracy of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2889.ErrorFramesFiltering</t> - - <t>Throughput.RFC2544.Profile</t> - </list></t> - </section> - - <section title="Reliability of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2889.Soak</t> - - <t>Throughput.RFC2889.SoakFrameModification</t> - - <t>PacketDelayVariation.RFC3393.Soak</t> - </list></t> - </section> - - <section title="Scalability of Operation"> - <t><list style="symbols"> - <t>Scalability.RFC2544.0PacketLoss</t> - - <t>MemoryBandwidth.RFC2544.0PacketLoss.Scalability</t> - </list></t> - </section> - - <section title="Summary"> - <t><figure> - <artwork><![CDATA[|------------------------------------------------------------------------| -| | | | | | -| | SPEED | ACCURACY | RELIABILITY | SCALE | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Activation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Operation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| De-activation | | | | | -| | | | | | -|------------------------------------------------------------------------|]]></artwork> - </figure></t> - </section> - </section> - - <section title="Security Considerations"> - <t>Benchmarking activities as described in this memo are limited to - technology characterization of a Device Under Test/System Under Test - (DUT/SUT) using controlled stimuli in a laboratory environment, with - dedicated address space and the constraints specified in the sections - above.</t> - - <t>The benchmarking network topology will be an independent test setup - and MUST NOT be connected to devices that may forward the test traffic - into a production network, or misroute traffic to the test management - network.</t> - - <t>Further, benchmarking is performed on a "black-box" basis, relying - solely on measurements observable external to the DUT/SUT.</t> - - <t>Special capabilities SHOULD NOT exist in the DUT/SUT specifically for - benchmarking purposes. Any implications for network security arising - from the DUT/SUT SHOULD be identical in the lab and in production - networks.</t> - </section> - - <section anchor="IANA" title="IANA Considerations"> - <t>No IANA Action is requested at this time.</t> - </section> - - <section title="Acknowledgements"> - <t>The authors acknowledge</t> - </section> - </middle> - - <back> - <references title="Normative References"> - <?rfc ?> - - <?rfc include="reference.RFC.2119"?> - - <?rfc include="reference.RFC.2330"?> - - <?rfc include='reference.RFC.2544'?> - - <?rfc include="reference.RFC.2679"?> - - <?rfc include='reference.RFC.2680'?> - - <?rfc include='reference.RFC.3393'?> - - <?rfc include='reference.RFC.3432'?> - - <?rfc include='reference.RFC.2681'?> - - <?rfc include='reference.RFC.5905'?> - - <?rfc include='reference.RFC.4689'?> - - <?rfc include='reference.RFC.4737'?> - - <?rfc include='reference.RFC.5357'?> - - <?rfc include='reference.RFC.2889'?> - - <?rfc include='reference.RFC.3918'?> - - <?rfc include='reference.RFC.6201'?> - - <?rfc include='reference.RFC.2285'?> - - <reference anchor="NFV.PER001"> - <front> - <title>Network Function Virtualization: Performance and Portability - Best Practices</title> - - <author fullname="ETSI NFV" initials="" surname=""> - <organization/> - </author> - - <date month="June" year="2014"/> - </front> - - <seriesInfo name="Group Specification" - value="ETSI GS NFV-PER 001 V1.1.1 (2014-06)"/> - - <format type="PDF"/> - </reference> - </references> - - <references title="Informative References"> - <?rfc include='reference.RFC.1242'?> - - <?rfc include='reference.RFC.5481'?> - - <?rfc include='reference.RFC.6049'?> - - <?rfc include='reference.RFC.6248'?> - - <?rfc include='reference.RFC.6390'?> - - <?rfc include='reference.I-D.ietf-bmwg-virtual-net'?> - - <reference anchor="TestTopo"> - <front> - <title>Test Topologies - https://wiki.opnfv.org/vsperf/test_methodology</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="LTDoverV"> - <front> - <title>LTD Test Spec Overview - https://wiki.opnfv.org/wiki/vswitchperf_test_spec_review </title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="IFA003"> - <front> - <title>https://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA003_Acceleration_-_vSwitch_Spec/</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - </references> - </back> -</rfc> diff --git a/docs/testing/developer/devguide/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.xml b/docs/testing/developer/devguide/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.xml deleted file mode 100644 index a9405a77..00000000 --- a/docs/testing/developer/devguide/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.xml +++ /dev/null @@ -1,1016 +0,0 @@ -<?xml version="1.0" encoding="US-ASCII"?> -<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -<?rfc toc="yes"?> -<?rfc tocompact="yes"?> -<?rfc tocdepth="3"?> -<?rfc tocindent="yes"?> -<?rfc symrefs="yes"?> -<?rfc sortrefs="yes"?> -<?rfc comments="yes"?> -<?rfc inline="yes"?> -<?rfc compact="yes"?> -<?rfc subcompact="no"?> -<rfc category="info" docName="draft-vsperf-bmwg-vswitch-opnfv-02" - ipr="trust200902"> - <front> - <title abbrev="Benchmarking vSwitches">Benchmarking Virtual Switches in - OPNFV</title> - - <author fullname="Maryam Tahhan" initials="M." surname="Tahhan"> - <organization>Intel</organization> - - <address> - <postal> - <street/> - - <city/> - - <region/> - - <code/> - - <country/> - </postal> - - <phone/> - - <facsimile/> - - <email>maryam.tahhan@intel.com</email> - - <uri/> - </address> - </author> - - <author fullname="Billy O'Mahony" initials="B." surname="O'Mahony"> - <organization>Intel</organization> - - <address> - <postal> - <street/> - - <city/> - - <region/> - - <code/> - - <country/> - </postal> - - <phone/> - - <facsimile/> - - <email>billy.o.mahony@intel.com</email> - - <uri/> - </address> - </author> - - <author fullname="Al Morton" initials="A." surname="Morton"> - <organization>AT&T Labs</organization> - - <address> - <postal> - <street>200 Laurel Avenue South</street> - - <city>Middletown,</city> - - <region>NJ</region> - - <code>07748</code> - - <country>USA</country> - </postal> - - <phone>+1 732 420 1571</phone> - - <facsimile>+1 732 368 1192</facsimile> - - <email>acmorton@att.com</email> - - <uri>http://home.comcast.net/~acmacm/</uri> - </address> - </author> - - <date day="20" month="March" year="2016"/> - - <abstract> - <t>This memo describes the progress of the Open Platform for NFV (OPNFV) - project on virtual switch performance "VSWITCHPERF". This project - intends to build on the current and completed work of the Benchmarking - Methodology Working Group in IETF, by referencing existing literature. - The Benchmarking Methodology Working Group has traditionally conducted - laboratory characterization of dedicated physical implementations of - internetworking functions. Therefore, this memo begins to describe the - additional considerations when virtual switches are implemented in - general-purpose hardware. The expanded tests and benchmarks are also - influenced by the OPNFV mission to support virtualization of the "telco" - infrastructure.</t> - </abstract> - - <note title="Requirements Language"> - <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in <xref - target="RFC2119">RFC 2119</xref>.</t> - - <t/> - </note> - </front> - - <middle> - <section title="Introduction"> - <t>Benchmarking Methodology Working Group (BMWG) has traditionally - conducted laboratory characterization of dedicated physical - implementations of internetworking functions. The Black-box Benchmarks - of Throughput, Latency, Forwarding Rates and others have served our - industry for many years. Now, Network Function Virtualization (NFV) has - the goal to transform how internetwork functions are implemented, and - therefore has garnered much attention.</t> - - <t>This memo summarizes the progress of the Open Platform for NFV - (OPNFV) project on virtual switch performance characterization, - "VSWITCHPERF", through the Brahmaputra (second) release <xref - target="BrahRel"/>. This project intends to build on the current and - completed work of the Benchmarking Methodology Working Group in IETF, by - referencing existing literature. For example, currently the most often - referenced RFC is <xref target="RFC2544"/> (which depends on <xref - target="RFC1242"/>) and foundation of the benchmarking work in OPNFV is - common and strong.</t> - - <t>See - https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases - for more background, and the OPNFV website for general information: - https://www.opnfv.org/</t> - - <t>The authors note that OPNFV distinguishes itself from other open - source compute and networking projects through its emphasis on existing - "telco" services as opposed to cloud-computing. There are many ways in - which telco requirements have different emphasis on performance - dimensions when compared to cloud computing: support for and transfer of - isochronous media streams is one example.</t> - - <t>Note also that the move to NFV Infrastructure has resulted in many - new benchmarking initiatives across the industry. The authors are - currently doing their best to maintain alignment with many other - projects, and this Internet Draft is one part of the efforts. We - acknowledge the early work in <xref - target="I-D.huang-bmwg-virtual-network-performance"/>, and useful - discussion with the authors.</t> - </section> - - <section title="Scope"> - <t>The primary purpose and scope of the memo is to inform the industry - of work-in-progress that builds on the body of extensive BMWG literature - and experience, and describe the extensions needed for benchmarking - virtual switches. Inital feedback indicates that many of these - extensions may be applicable beyond the current scope (to hardware - switches in the NFV Infrastructure and to virtual routers, for example). - Additionally, this memo serves as a vehicle to include more detail and - commentary from BMWG and other Open Source communities, under BMWG's - chartered work to characterize the NFV Infrastructure (a virtual switch - is an important aspect of that infrastructure).</t> - </section> - - <section title="Benchmarking Considerations"> - <t>This section highlights some specific considerations (from <xref - target="I-D.ietf-bmwg-virtual-net"/>)related to Benchmarks for virtual - switches. The OPNFV project is sharing its present view on these areas, - as they develop their specifications in the Level Test Design (LTD) - document.</t> - - <section title="Comparison with Physical Network Functions"> - <t>To compare the performance of virtual designs and implementations - with their physical counterparts, identical benchmarks are needed. - BMWG has developed specifications for many network functions this memo - re-uses existing benchmarks through references, and expands them - during development of new methods. A key configuration aspect is the - number of parallel cores required to achieve comparable performance - with a given physical device, or whether some limit of scale was - reached before the cores could achieve the comparable level.</t> - - <t>It's unlikely that the virtual switch will be the only application - running on the SUT, so CPU utilization, Cache utilization, and Memory - footprint should also be recorded for the virtual implementations of - internetworking functions.</t> - </section> - - <section title="Continued Emphasis on Black-Box Benchmarks"> - <t>External observations remain essential as the basis for Benchmarks. - Internal observations with fixed specification and interpretation will - be provided in parallel to assist the development of operations - procedures when the technology is deployed.</t> - </section> - - <section title="New Configuration Parameters"> - <t>A key consideration when conducting any sort of benchmark is trying - to ensure the consistency and repeatability of test results. When - benchmarking the performance of a vSwitch there are many factors that - can affect the consistency of results, one key factor is matching the - various hardware and software details of the SUT. This section lists - some of the many new parameters which this project believes are - critical to report in order to achieve repeatability.</t> - - <t>Hardware details including:</t> - - <t><list style="symbols"> - <t>Platform details</t> - - <t>Processor details</t> - - <t>Memory information (type and size)</t> - - <t>Number of enabled cores</t> - - <t>Number of cores used for the test</t> - - <t>Number of physical NICs, as well as their details - (manufacturer, versions, type and the PCI slot they are plugged - into)</t> - - <t>NIC interrupt configuration</t> - - <t>BIOS version, release date and any configurations that were - modified</t> - - <t>CPU microcode level</t> - - <t>Memory DIMM configurations (quad rank performance may not be - the same as dual rank) in size, freq and slot locations</t> - - <t>PCI configuration parameters (payload size, early ack - option...)</t> - - <t>Power management at all levels (ACPI sleep states, processor - package, OS...)</t> - </list>Software details including:</t> - - <t><list style="symbols"> - <t>OS parameters and behavior (text vs graphical no one typing at - the console on one system)</t> - - <t>OS version (for host and VNF)</t> - - <t>Kernel version (for host and VNF)</t> - - <t>GRUB boot parameters (for host and VNF)</t> - - <t>Hypervisor details (Type and version)</t> - - <t>Selected vSwitch, version number or commit id used</t> - - <t>vSwitch launch command line if it has been parameterised</t> - - <t>Memory allocation to the vSwitch</t> - - <t>which NUMA node it is using, and how many memory channels</t> - - <t>DPDK or any other SW dependency version number or commit id - used</t> - - <t>Memory allocation to a VM - if it's from Hugpages/elsewhere</t> - - <t>VM storage type: snapshot/independent persistent/independent - non-persistent</t> - - <t>Number of VMs</t> - - <t>Number of Virtual NICs (vNICs), versions, type and driver</t> - - <t>Number of virtual CPUs and their core affinity on the host</t> - - <t>Number vNIC interrupt configuration</t> - - <t>Thread affinitization for the applications (including the - vSwitch itself) on the host</t> - - <t>Details of Resource isolation, such as CPUs designated for - Host/Kernel (isolcpu) and CPUs designated for specific processes - (taskset). - Test duration. - Number of flows.</t> - </list></t> - - <t>Test Traffic Information:<list style="symbols"> - <t>Traffic type - UDP, TCP, IMIX / Other</t> - - <t>Packet Sizes</t> - - <t>Deployment Scenario</t> - </list></t> - - <t/> - </section> - - <section title="Flow classification"> - <t>Virtual switches group packets into flows by processing and - matching particular packet or frame header information, or by matching - packets based on the input ports. Thus a flow can be thought of a - sequence of packets that have the same set of header field values or - have arrived on the same port. Performance results can vary based on - the parameters the vSwitch uses to match for a flow. The recommended - flow classification parameters for any vSwitch performance tests are: - the input port, the source IP address, the destination IP address and - the Ethernet protocol type field. It is essential to increase the flow - timeout time on a vSwitch before conducting any performance tests that - do not measure the flow setup time. Normally the first packet of a - particular stream will install the flow in the virtual switch which - adds an additional latency, subsequent packets of the same flow are - not subject to this latency if the flow is already installed on the - vSwitch.</t> - </section> - - <section title="Benchmarks using Baselines with Resource Isolation"> - <t>This outline describes measurement of baseline with isolated - resources at a high level, which is the intended approach at this - time.</t> - - <t><list style="numbers"> - <t>Baselines: <list style="symbols"> - <t>Optional: Benchmark platform forwarding capability without - a vswitch or VNF for at least 72 hours (serves as a means of - platform validation and a means to obtain the base performance - for the platform in terms of its maximum forwarding rate and - latency). <figure> - <preamble>Benchmark platform forwarding - capability</preamble> - - <artwork align="right"><![CDATA[ __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | Simple Forwarding App | | Host - | | | | | - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - - <postamble/> - </figure></t> - - <t>Benchmark VNF forwarding capability with direct - connectivity (vSwitch bypass, e.g., SR/IOV) for at least 72 - hours (serves as a means of VNF validation and a means to - obtain the base performance for the VNF in terms of its - maximum forwarding rate and latency). The metrics gathered - from this test will serve as a key comparison point for - vSwitch bypass technologies performance and vSwitch - performance. <figure align="right"> - <preamble>Benchmark VNF forwarding capability</preamble> - - <artwork><![CDATA[ __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | VNF | | | - | | | | | - | +------------------------------------------+ | | - | | Passthrough/SR-IOV | | Host - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - - <postamble/> - </figure></t> - - <t>Benchmarking with isolated resources alone, with other - resources (both HW&SW) disabled Example, vSw and VM are - SUT</t> - - <t>Benchmarking with isolated resources alone, leaving some - resources unused</t> - - <t>Benchmark with isolated resources and all resources - occupied</t> - </list></t> - - <t>Next Steps<list style="symbols"> - <t>Limited sharing</t> - - <t>Production scenarios</t> - - <t>Stressful scenarios</t> - </list></t> - </list></t> - </section> - </section> - - <section title="VSWITCHPERF Specification Summary"> - <t>The overall specification in preparation is referred to as a Level - Test Design (LTD) document, which will contain a suite of performance - tests. The base performance tests in the LTD are based on the - pre-existing specifications developed by BMWG to test the performance of - physical switches. These specifications include:</t> - - <t><list style="symbols"> - <t><xref target="RFC2544"/> Benchmarking Methodology for Network - Interconnect Devices</t> - - <t><xref target="RFC2889"/> Benchmarking Methodology for LAN - Switching</t> - - <t><xref target="RFC6201"/> Device Reset Characterization</t> - - <t><xref target="RFC5481"/> Packet Delay Variation Applicability - Statement</t> - </list></t> - - <t>Some of the above/newer RFCs are being applied in benchmarking for - the first time, and represent a development challenge for test equipment - developers. Fortunately, many members of the testing system community - have engaged on the VSPERF project, including an open source test - system.</t> - - <t>In addition to this, the LTD also re-uses the terminology defined - by:</t> - - <t><list style="symbols"> - <t><xref target="RFC2285"/> Benchmarking Terminology for LAN - Switching Devices</t> - - <t><xref target="RFC5481"/> Packet Delay Variation Applicability - Statement</t> - </list></t> - - <t/> - - <t>Specifications to be included in future updates of the LTD - include:<list style="symbols"> - <t><xref target="RFC3918"/> Methodology for IP Multicast - Benchmarking</t> - - <t><xref target="RFC4737"/> Packet Reordering Metrics</t> - </list></t> - - <t>As one might expect, the most fundamental internetworking - characteristics of Throughput and Latency remain important when the - switch is virtualized, and these benchmarks figure prominently in the - specification.</t> - - <t>When considering characteristics important to "telco" network - functions, we must begin to consider additional performance metrics. In - this case, the project specifications have referenced metrics from the - IETF IP Performance Metrics (IPPM) literature. This means that the <xref - target="RFC2544"/> test of Latency is replaced by measurement of a - metric derived from IPPM's <xref target="RFC2679"/>, where a set of - statistical summaries will be provided (mean, max, min, etc.). Further - metrics planned to be benchmarked include packet delay variation as - defined by <xref target="RFC5481"/> , reordering, burst behaviour, DUT - availability, DUT capacity and packet loss in long term testing at - Throughput level, where some low-level of background loss may be present - and characterized.</t> - - <t>Tests have been (or will be) designed to collect the metrics - below:</t> - - <t><list style="symbols"> - <t>Throughput Tests to measure the maximum forwarding rate (in - frames per second or fps) and bit rate (in Mbps) for a constant load - (as defined by <xref target="RFC1242"/>) without traffic loss.</t> - - <t>Packet and Frame Delay Distribution Tests to measure average, min - and max packet and frame delay for constant loads.</t> - - <t>Packet Delay Tests to understand latency distribution for - different packet sizes and over an extended test run to uncover - outliers.</t> - - <t>Scalability Tests to understand how the virtual switch performs - as the number of flows, active ports, complexity of the forwarding - logic’s configuration… it has to deal with - increases.</t> - - <t>Stream Performance Tests (TCP, UDP) to measure bulk data transfer - performance, i.e. how fast systems can send and receive data through - the switch.</t> - - <t>Control Path and Datapath Coupling Tests, to understand how - closely coupled the datapath and the control path are as well as the - effect of this coupling on the performance of the DUT (example: - delay of the initial packet of a flow).</t> - - <t>CPU and Memory Consumption Tests to understand the virtual - switch’s footprint on the system, usually conducted as - auxiliary measurements with benchmarks above. They include: CPU - utilization, Cache utilization and Memory footprint.</t> - - <t>The so-called "Soak" tests, where the selected test is conducted - over a long period of time (with an ideal duration of 24 hours, and - at least 6 hours). The purpose of soak tests is to capture transient - changes in performance which may occur due to infrequent processes - or the low probability coincidence of two or more processes. The - performance must be evaluated periodically during continuous - testing, and this results in use of <xref target="RFC2889"/> Frame - Rate metrics instead of <xref target="RFC2544"/> Throughput (which - requires stopping traffic to allow time for all traffic to exit - internal queues).</t> - </list></t> - - <t>Future/planned test specs include:<list style="symbols"> - <t>Request/Response Performance Tests (TCP, UDP) which measure the - transaction rate through the switch.</t> - - <t>Noisy Neighbour Tests, to understand the effects of resource - sharing on the performance of a virtual switch.</t> - - <t>Tests derived from examination of ETSI NFV Draft GS IFA003 - requirements <xref target="IFA003"/> on characterization of - acceleration technologies applied to vswitches.</t> - </list>The flexibility of deployment of a virtual switch within a - network means that the BMWG IETF existing literature needs to be used to - characterize the performance of a switch in various deployment - scenarios. The deployment scenarios under consideration include:</t> - - <t><figure> - <preamble>Physical port to virtual switch to physical - port</preamble> - - <artwork><![CDATA[ __ - +--------------------------------------------------+ | - | +--------------------+ | | - | | | | | - | | v | | Host - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure></t> - - <t><figure> - <preamble>Physical port to virtual switch to VNF to virtual switch - to physical port</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ : | | - | | | | | Guest - | : v | | - | +---------------+ +---------------+ | | - | | logical port 0| | logical port 1| | | - +---+---------------+-----------+---------------+---+ __| - ^ : - | | - : v __ - +---+---------------+----------+---------------+---+ | - | | logical port 0| | logical port 1| | | - | +---------------+ +---------------+ | | - | ^ : | | - | | | | | Host - | : v | | - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>Physical port to virtual switch to VNF to virtual switch - to VNF to virtual switch to physical port</preamble> - - <artwork><![CDATA[ __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | ^ | | | ^ | | | - | | v | | | v | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 1 | | | | 0 1 | | | - +---+---------------+--+ +---+---------------+--+__| - ^ : ^ : - | | | | - : v : v _ - +---+---------------+---------+---------------+--+ | - | | 0 1 | | 3 4 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | ^ | ^ | | | Host - | | |-----------------| v | | - | +--------------+ +--------------+ | | - | | phy ports | vSwitch | phy ports | | | - +---+--------------+----------+--------------+---+_| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>Physical port to virtual switch to VNF</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ | | - | | | | Guest - | : | | - | +---------------+ | | - | | logical port 0| | | - +---+---------------+-------------------------------+ __| - ^ - | - : __ - +---+---------------+------------------------------+ | - | | logical port 0| | | - | +---------------+ | | - | ^ | | - | | | | Host - | : | | - | +--------------+ | | - | | phy port | vSwitch | | - +---+--------------+------------ -------------- ---+ __| - ^ - | - : - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>VNF to virtual switch to physical port</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | : | | - | | | | Guest - | v | | - | +---------------+ | | - | | logical port | | | - +-------------------------------+---------------+---+ __| - : - | - v __ - +------------------------------+---------------+---+ | - | | logical port | | | - | +---------------+ | | - | : | | - | | | | Host - | v | | - | +--------------+ | | - | vSwitch | phy port | | | - +-------------------------------+--------------+---+ __| - : - | - v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>VNF to virtual switch to VNF</preamble> - - <artwork><![CDATA[ __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | | | | ^ | | - | v | | | | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 | | | | 0 | | | - +---+---------------+--+ +---+---------------+--+__| - : ^ - | | - v : _ - +---+---------------+---------+---------------+--+ | - | | 1 | | 1 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | | ^ | | Host - | L-----------------+ | | - | | | - | vSwitch | | - +------------------------------------------------+_|]]></artwork> - </figure></t> - - <t>A set of Deployment Scenario figures is available on the VSPERF Test - Methodology Wiki page <xref target="TestTopo"/>.</t> - </section> - - <section title="3x3 Matrix Coverage"> - <t>This section organizes the many existing test specifications into the - "3x3" matrix (introduced in <xref target="I-D.ietf-bmwg-virtual-net"/>). - Because the LTD specification ID names are quite long, this section is - organized into lists for each occupied cell of the matrix (not all are - occupied, also the matrix has grown to 3x4 to accommodate scale metrics - when displaying the coverage of many metrics/benchmarks). The current - version of the LTD specification is available <xref target="LTD"/>.</t> - - <t>The tests listed below assess the activation of paths in the data - plane, rather than the control plane.</t> - - <t>A complete list of tests with short summaries is available on the - VSPERF "LTD Test Spec Overview" Wiki page <xref target="LTDoverV"/>.</t> - - <section title="Speed of Activation"> - <t><list style="symbols"> - <t>Activation.RFC2889.AddressLearningRate</t> - - <t>PacketLatency.InitialPacketProcessingLatency</t> - </list></t> - </section> - - <section title="Accuracy of Activation section"> - <t><list style="symbols"> - <t>CPDP.Coupling.Flow.Addition</t> - </list></t> - </section> - - <section title="Reliability of Activation"> - <t><list style="symbols"> - <t>Throughput.RFC2544.SystemRecoveryTime</t> - - <t>Throughput.RFC2544.ResetTime</t> - </list></t> - </section> - - <section title="Scale of Activation"> - <t><list style="symbols"> - <t>Activation.RFC2889.AddressCachingCapacity</t> - </list></t> - </section> - - <section title="Speed of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2544.PacketLossRate</t> - - <t>CPU.RFC2544.0PacketLoss</t> - - <t>Throughput.RFC2544.PacketLossRateFrameModification</t> - - <t>Throughput.RFC2544.BackToBackFrames</t> - - <t>Throughput.RFC2889.MaxForwardingRate</t> - - <t>Throughput.RFC2889.ForwardPressure</t> - - <t>Throughput.RFC2889.BroadcastFrameForwarding</t> - </list></t> - </section> - - <section title="Accuracy of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2889.ErrorFramesFiltering</t> - - <t>Throughput.RFC2544.Profile</t> - </list></t> - </section> - - <section title="Reliability of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2889.Soak</t> - - <t>Throughput.RFC2889.SoakFrameModification</t> - - <t>PacketDelayVariation.RFC3393.Soak</t> - </list></t> - </section> - - <section title="Scalability of Operation"> - <t><list style="symbols"> - <t>Scalability.RFC2544.0PacketLoss</t> - - <t>MemoryBandwidth.RFC2544.0PacketLoss.Scalability</t> - </list></t> - </section> - - <section title="Summary"> - <t><figure> - <artwork><![CDATA[|------------------------------------------------------------------------| -| | | | | | -| | SPEED | ACCURACY | RELIABILITY | SCALE | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Activation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Operation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| De-activation | | | | | -| | | | | | -|------------------------------------------------------------------------|]]></artwork> - </figure></t> - </section> - </section> - - <section title="Security Considerations"> - <t>Benchmarking activities as described in this memo are limited to - technology characterization of a Device Under Test/System Under Test - (DUT/SUT) using controlled stimuli in a laboratory environment, with - dedicated address space and the constraints specified in the sections - above.</t> - - <t>The benchmarking network topology will be an independent test setup - and MUST NOT be connected to devices that may forward the test traffic - into a production network, or misroute traffic to the test management - network.</t> - - <t>Further, benchmarking is performed on a "black-box" basis, relying - solely on measurements observable external to the DUT/SUT.</t> - - <t>Special capabilities SHOULD NOT exist in the DUT/SUT specifically for - benchmarking purposes. Any implications for network security arising - from the DUT/SUT SHOULD be identical in the lab and in production - networks.</t> - </section> - - <section anchor="IANA" title="IANA Considerations"> - <t>No IANA Action is requested at this time.</t> - </section> - - <section title="Acknowledgements"> - <t>The authors appreciate and acknowledge comments from Scott Bradner, - Marius Georgescu, Ramki Krishnan, and Doug Montgomery, and others for - their reviews.</t> - </section> - </middle> - - <back> - <references title="Normative References"> - <?rfc ?> - - <?rfc include="reference.RFC.2119"?> - - <?rfc ?> - - <?rfc include="reference.RFC.2330"?> - - <?rfc include='reference.RFC.2544'?> - - <?rfc include="reference.RFC.2679"?> - - <?rfc include='reference.RFC.2680'?> - - <?rfc include='reference.RFC.3393'?> - - <?rfc include='reference.RFC.3432'?> - - <?rfc include='reference.RFC.2681'?> - - <?rfc include='reference.RFC.5905'?> - - <?rfc include='reference.RFC.4689'?> - - <?rfc include='reference.RFC.4737'?> - - <?rfc include='reference.RFC.5357'?> - - <?rfc include='reference.RFC.2889'?> - - <?rfc include='reference.RFC.3918'?> - - <?rfc include='reference.RFC.6201'?> - - <?rfc include='reference.RFC.2285'?> - - <reference anchor="NFV.PER001"> - <front> - <title>Network Function Virtualization: Performance and Portability - Best Practices</title> - - <author fullname="ETSI NFV" initials="" surname=""> - <organization/> - </author> - - <date month="June" year="2014"/> - </front> - - <seriesInfo name="Group Specification" - value="ETSI GS NFV-PER 001 V1.1.1 (2014-06)"/> - - <format type="PDF"/> - </reference> - </references> - - <references title="Informative References"> - <?rfc include='reference.RFC.1242'?> - - <?rfc include='reference.RFC.5481'?> - - <?rfc include='reference.RFC.6049'?> - - <?rfc include='reference.RFC.6248'?> - - <?rfc include='reference.RFC.6390'?> - - <?rfc include='reference.I-D.ietf-bmwg-virtual-net'?> - - <?rfc include='reference.I-D.huang-bmwg-virtual-network-performance'?> - - <reference anchor="TestTopo"> - <front> - <title>Test Topologies - https://wiki.opnfv.org/vsperf/test_methodology</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="LTDoverV"> - <front> - <title>LTD Test Spec Overview - https://wiki.opnfv.org/wiki/vswitchperf_test_spec_review</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="LTD"> - <front> - <title>LTD Test Specification - http://artifacts.opnfv.org/vswitchperf/docs/requirements/index.html</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="BrahRel"> - <front> - <title>Brahmaputra, Second OPNFV Release - https://www.opnfv.org/brahmaputra</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="IFA003"> - <front> - <title>https://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA003_Acceleration_-_vSwitch_Spec/</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - </references> - </back> -</rfc> diff --git a/docs/testing/developer/devguide/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-02.xml b/docs/testing/developer/devguide/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-02.xml deleted file mode 100644 index 9157763e..00000000 --- a/docs/testing/developer/devguide/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-02.xml +++ /dev/null @@ -1,1016 +0,0 @@ -<?xml version="1.0" encoding="US-ASCII"?> -<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -<?rfc toc="yes"?> -<?rfc tocompact="yes"?> -<?rfc tocdepth="3"?> -<?rfc tocindent="yes"?> -<?rfc symrefs="yes"?> -<?rfc sortrefs="yes"?> -<?rfc comments="yes"?> -<?rfc inline="yes"?> -<?rfc compact="yes"?> -<?rfc subcompact="no"?> -<rfc category="info" docName="draft-vsperf-bmwg-vswitch-opnfv-02" - ipr="trust200902"> - <front> - <title abbrev="Benchmarking vSwitches">Benchmarking Virtual Switches in - OPNFV</title> - - <author fullname="Maryam Tahhan" initials="M." surname="Tahhan"> - <organization>Intel</organization> - - <address> - <postal> - <street/> - - <city/> - - <region/> - - <code/> - - <country/> - </postal> - - <phone/> - - <facsimile/> - - <email>maryam.tahhan@intel.com</email> - - <uri/> - </address> - </author> - - <author fullname="Billy O'Mahony" initials="B." surname="O'Mahony"> - <organization>Intel</organization> - - <address> - <postal> - <street/> - - <city/> - - <region/> - - <code/> - - <country/> - </postal> - - <phone/> - - <facsimile/> - - <email>billy.o.mahony@intel.com</email> - - <uri/> - </address> - </author> - - <author fullname="Al Morton" initials="A." surname="Morton"> - <organization>AT&T Labs</organization> - - <address> - <postal> - <street>200 Laurel Avenue South</street> - - <city>Middletown,</city> - - <region>NJ</region> - - <code>07748</code> - - <country>USA</country> - </postal> - - <phone>+1 732 420 1571</phone> - - <facsimile>+1 732 368 1192</facsimile> - - <email>acmorton@att.com</email> - - <uri>http://home.comcast.net/~acmacm/</uri> - </address> - </author> - - <date day="21" month="March" year="2016"/> - - <abstract> - <t>This memo describes the progress of the Open Platform for NFV (OPNFV) - project on virtual switch performance "VSWITCHPERF". This project - intends to build on the current and completed work of the Benchmarking - Methodology Working Group in IETF, by referencing existing literature. - The Benchmarking Methodology Working Group has traditionally conducted - laboratory characterization of dedicated physical implementations of - internetworking functions. Therefore, this memo begins to describe the - additional considerations when virtual switches are implemented in - general-purpose hardware. The expanded tests and benchmarks are also - influenced by the OPNFV mission to support virtualization of the "telco" - infrastructure.</t> - </abstract> - - <note title="Requirements Language"> - <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in <xref - target="RFC2119">RFC 2119</xref>.</t> - - <t/> - </note> - </front> - - <middle> - <section title="Introduction"> - <t>Benchmarking Methodology Working Group (BMWG) has traditionally - conducted laboratory characterization of dedicated physical - implementations of internetworking functions. The Black-box Benchmarks - of Throughput, Latency, Forwarding Rates and others have served our - industry for many years. Now, Network Function Virtualization (NFV) has - the goal to transform how internetwork functions are implemented, and - therefore has garnered much attention.</t> - - <t>This memo summarizes the progress of the Open Platform for NFV - (OPNFV) project on virtual switch performance characterization, - "VSWITCHPERF", through the Brahmaputra (second) release <xref - target="BrahRel"/>. This project intends to build on the current and - completed work of the Benchmarking Methodology Working Group in IETF, by - referencing existing literature. For example, currently the most often - referenced RFC is <xref target="RFC2544"/> (which depends on <xref - target="RFC1242"/>) and foundation of the benchmarking work in OPNFV is - common and strong.</t> - - <t>See - https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases - for more background, and the OPNFV website for general information: - https://www.opnfv.org/</t> - - <t>The authors note that OPNFV distinguishes itself from other open - source compute and networking projects through its emphasis on existing - "telco" services as opposed to cloud-computing. There are many ways in - which telco requirements have different emphasis on performance - dimensions when compared to cloud computing: support for and transfer of - isochronous media streams is one example.</t> - - <t>Note also that the move to NFV Infrastructure has resulted in many - new benchmarking initiatives across the industry. The authors are - currently doing their best to maintain alignment with many other - projects, and this Internet Draft is one part of the efforts. We - acknowledge the early work in <xref - target="I-D.huang-bmwg-virtual-network-performance"/>, and useful - discussion with the authors.</t> - </section> - - <section title="Scope"> - <t>The primary purpose and scope of the memo is to inform the industry - of work-in-progress that builds on the body of extensive BMWG literature - and experience, and describe the extensions needed for benchmarking - virtual switches. Inital feedback indicates that many of these - extensions may be applicable beyond the current scope (to hardware - switches in the NFV Infrastructure and to virtual routers, for example). - Additionally, this memo serves as a vehicle to include more detail and - commentary from BMWG and other Open Source communities, under BMWG's - chartered work to characterize the NFV Infrastructure (a virtual switch - is an important aspect of that infrastructure).</t> - </section> - - <section title="Benchmarking Considerations"> - <t>This section highlights some specific considerations (from <xref - target="I-D.ietf-bmwg-virtual-net"/>)related to Benchmarks for virtual - switches. The OPNFV project is sharing its present view on these areas, - as they develop their specifications in the Level Test Design (LTD) - document.</t> - - <section title="Comparison with Physical Network Functions"> - <t>To compare the performance of virtual designs and implementations - with their physical counterparts, identical benchmarks are needed. - BMWG has developed specifications for many network functions this memo - re-uses existing benchmarks through references, and expands them - during development of new methods. A key configuration aspect is the - number of parallel cores required to achieve comparable performance - with a given physical device, or whether some limit of scale was - reached before the cores could achieve the comparable level.</t> - - <t>It's unlikely that the virtual switch will be the only application - running on the SUT, so CPU utilization, Cache utilization, and Memory - footprint should also be recorded for the virtual implementations of - internetworking functions.</t> - </section> - - <section title="Continued Emphasis on Black-Box Benchmarks"> - <t>External observations remain essential as the basis for Benchmarks. - Internal observations with fixed specification and interpretation will - be provided in parallel to assist the development of operations - procedures when the technology is deployed.</t> - </section> - - <section title="New Configuration Parameters"> - <t>A key consideration when conducting any sort of benchmark is trying - to ensure the consistency and repeatability of test results. When - benchmarking the performance of a vSwitch there are many factors that - can affect the consistency of results, one key factor is matching the - various hardware and software details of the SUT. This section lists - some of the many new parameters which this project believes are - critical to report in order to achieve repeatability.</t> - - <t>Hardware details including:</t> - - <t><list style="symbols"> - <t>Platform details</t> - - <t>Processor details</t> - - <t>Memory information (type and size)</t> - - <t>Number of enabled cores</t> - - <t>Number of cores used for the test</t> - - <t>Number of physical NICs, as well as their details - (manufacturer, versions, type and the PCI slot they are plugged - into)</t> - - <t>NIC interrupt configuration</t> - - <t>BIOS version, release date and any configurations that were - modified</t> - - <t>CPU microcode level</t> - - <t>Memory DIMM configurations (quad rank performance may not be - the same as dual rank) in size, freq and slot locations</t> - - <t>PCI configuration parameters (payload size, early ack - option...)</t> - - <t>Power management at all levels (ACPI sleep states, processor - package, OS...)</t> - </list>Software details including:</t> - - <t><list style="symbols"> - <t>OS parameters and behavior (text vs graphical no one typing at - the console on one system)</t> - - <t>OS version (for host and VNF)</t> - - <t>Kernel version (for host and VNF)</t> - - <t>GRUB boot parameters (for host and VNF)</t> - - <t>Hypervisor details (Type and version)</t> - - <t>Selected vSwitch, version number or commit id used</t> - - <t>vSwitch launch command line if it has been parameterised</t> - - <t>Memory allocation to the vSwitch</t> - - <t>which NUMA node it is using, and how many memory channels</t> - - <t>DPDK or any other SW dependency version number or commit id - used</t> - - <t>Memory allocation to a VM - if it's from Hugpages/elsewhere</t> - - <t>VM storage type: snapshot/independent persistent/independent - non-persistent</t> - - <t>Number of VMs</t> - - <t>Number of Virtual NICs (vNICs), versions, type and driver</t> - - <t>Number of virtual CPUs and their core affinity on the host</t> - - <t>Number vNIC interrupt configuration</t> - - <t>Thread affinitization for the applications (including the - vSwitch itself) on the host</t> - - <t>Details of Resource isolation, such as CPUs designated for - Host/Kernel (isolcpu) and CPUs designated for specific processes - (taskset). - Test duration. - Number of flows.</t> - </list></t> - - <t>Test Traffic Information:<list style="symbols"> - <t>Traffic type - UDP, TCP, IMIX / Other</t> - - <t>Packet Sizes</t> - - <t>Deployment Scenario</t> - </list></t> - - <t/> - </section> - - <section title="Flow classification"> - <t>Virtual switches group packets into flows by processing and - matching particular packet or frame header information, or by matching - packets based on the input ports. Thus a flow can be thought of a - sequence of packets that have the same set of header field values or - have arrived on the same port. Performance results can vary based on - the parameters the vSwitch uses to match for a flow. The recommended - flow classification parameters for any vSwitch performance tests are: - the input port, the source IP address, the destination IP address and - the Ethernet protocol type field. It is essential to increase the flow - timeout time on a vSwitch before conducting any performance tests that - do not measure the flow setup time. Normally the first packet of a - particular stream will install the flow in the virtual switch which - adds an additional latency, subsequent packets of the same flow are - not subject to this latency if the flow is already installed on the - vSwitch.</t> - </section> - - <section title="Benchmarks using Baselines with Resource Isolation"> - <t>This outline describes measurement of baseline with isolated - resources at a high level, which is the intended approach at this - time.</t> - - <t><list style="numbers"> - <t>Baselines: <list style="symbols"> - <t>Optional: Benchmark platform forwarding capability without - a vswitch or VNF for at least 72 hours (serves as a means of - platform validation and a means to obtain the base performance - for the platform in terms of its maximum forwarding rate and - latency). <figure> - <preamble>Benchmark platform forwarding - capability</preamble> - - <artwork align="right"><![CDATA[ __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | Simple Forwarding App | | Host - | | | | | - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - - <postamble/> - </figure></t> - - <t>Benchmark VNF forwarding capability with direct - connectivity (vSwitch bypass, e.g., SR/IOV) for at least 72 - hours (serves as a means of VNF validation and a means to - obtain the base performance for the VNF in terms of its - maximum forwarding rate and latency). The metrics gathered - from this test will serve as a key comparison point for - vSwitch bypass technologies performance and vSwitch - performance. <figure align="right"> - <preamble>Benchmark VNF forwarding capability</preamble> - - <artwork><![CDATA[ __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | VNF | | | - | | | | | - | +------------------------------------------+ | | - | | Passthrough/SR-IOV | | Host - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - - <postamble/> - </figure></t> - - <t>Benchmarking with isolated resources alone, with other - resources (both HW&SW) disabled Example, vSw and VM are - SUT</t> - - <t>Benchmarking with isolated resources alone, leaving some - resources unused</t> - - <t>Benchmark with isolated resources and all resources - occupied</t> - </list></t> - - <t>Next Steps<list style="symbols"> - <t>Limited sharing</t> - - <t>Production scenarios</t> - - <t>Stressful scenarios</t> - </list></t> - </list></t> - </section> - </section> - - <section title="VSWITCHPERF Specification Summary"> - <t>The overall specification in preparation is referred to as a Level - Test Design (LTD) document, which will contain a suite of performance - tests. The base performance tests in the LTD are based on the - pre-existing specifications developed by BMWG to test the performance of - physical switches. These specifications include:</t> - - <t><list style="symbols"> - <t><xref target="RFC2544"/> Benchmarking Methodology for Network - Interconnect Devices</t> - - <t><xref target="RFC2889"/> Benchmarking Methodology for LAN - Switching</t> - - <t><xref target="RFC6201"/> Device Reset Characterization</t> - - <t><xref target="RFC5481"/> Packet Delay Variation Applicability - Statement</t> - </list></t> - - <t>Some of the above/newer RFCs are being applied in benchmarking for - the first time, and represent a development challenge for test equipment - developers. Fortunately, many members of the testing system community - have engaged on the VSPERF project, including an open source test - system.</t> - - <t>In addition to this, the LTD also re-uses the terminology defined - by:</t> - - <t><list style="symbols"> - <t><xref target="RFC2285"/> Benchmarking Terminology for LAN - Switching Devices</t> - - <t><xref target="RFC5481"/> Packet Delay Variation Applicability - Statement</t> - </list></t> - - <t/> - - <t>Specifications to be included in future updates of the LTD - include:<list style="symbols"> - <t><xref target="RFC3918"/> Methodology for IP Multicast - Benchmarking</t> - - <t><xref target="RFC4737"/> Packet Reordering Metrics</t> - </list></t> - - <t>As one might expect, the most fundamental internetworking - characteristics of Throughput and Latency remain important when the - switch is virtualized, and these benchmarks figure prominently in the - specification.</t> - - <t>When considering characteristics important to "telco" network - functions, we must begin to consider additional performance metrics. In - this case, the project specifications have referenced metrics from the - IETF IP Performance Metrics (IPPM) literature. This means that the <xref - target="RFC2544"/> test of Latency is replaced by measurement of a - metric derived from IPPM's <xref target="RFC2679"/>, where a set of - statistical summaries will be provided (mean, max, min, etc.). Further - metrics planned to be benchmarked include packet delay variation as - defined by <xref target="RFC5481"/> , reordering, burst behaviour, DUT - availability, DUT capacity and packet loss in long term testing at - Throughput level, where some low-level of background loss may be present - and characterized.</t> - - <t>Tests have been (or will be) designed to collect the metrics - below:</t> - - <t><list style="symbols"> - <t>Throughput Tests to measure the maximum forwarding rate (in - frames per second or fps) and bit rate (in Mbps) for a constant load - (as defined by <xref target="RFC1242"/>) without traffic loss.</t> - - <t>Packet and Frame Delay Distribution Tests to measure average, min - and max packet and frame delay for constant loads.</t> - - <t>Packet Delay Tests to understand latency distribution for - different packet sizes and over an extended test run to uncover - outliers.</t> - - <t>Scalability Tests to understand how the virtual switch performs - as the number of flows, active ports, complexity of the forwarding - logic’s configuration… it has to deal with - increases.</t> - - <t>Stream Performance Tests (TCP, UDP) to measure bulk data transfer - performance, i.e. how fast systems can send and receive data through - the switch.</t> - - <t>Control Path and Datapath Coupling Tests, to understand how - closely coupled the datapath and the control path are as well as the - effect of this coupling on the performance of the DUT (example: - delay of the initial packet of a flow).</t> - - <t>CPU and Memory Consumption Tests to understand the virtual - switch’s footprint on the system, usually conducted as - auxiliary measurements with benchmarks above. They include: CPU - utilization, Cache utilization and Memory footprint.</t> - - <t>The so-called "Soak" tests, where the selected test is conducted - over a long period of time (with an ideal duration of 24 hours, and - at least 6 hours). The purpose of soak tests is to capture transient - changes in performance which may occur due to infrequent processes - or the low probability coincidence of two or more processes. The - performance must be evaluated periodically during continuous - testing, and this results in use of <xref target="RFC2889"/> Frame - Rate metrics instead of <xref target="RFC2544"/> Throughput (which - requires stopping traffic to allow time for all traffic to exit - internal queues).</t> - </list></t> - - <t>Future/planned test specs include:<list style="symbols"> - <t>Request/Response Performance Tests (TCP, UDP) which measure the - transaction rate through the switch.</t> - - <t>Noisy Neighbour Tests, to understand the effects of resource - sharing on the performance of a virtual switch.</t> - - <t>Tests derived from examination of ETSI NFV Draft GS IFA003 - requirements <xref target="IFA003"/> on characterization of - acceleration technologies applied to vswitches.</t> - </list>The flexibility of deployment of a virtual switch within a - network means that the BMWG IETF existing literature needs to be used to - characterize the performance of a switch in various deployment - scenarios. The deployment scenarios under consideration include:</t> - - <t><figure> - <preamble>Physical port to virtual switch to physical - port</preamble> - - <artwork><![CDATA[ __ - +--------------------------------------------------+ | - | +--------------------+ | | - | | | | | - | | v | | Host - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure></t> - - <t><figure> - <preamble>Physical port to virtual switch to VNF to virtual switch - to physical port</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ : | | - | | | | | Guest - | : v | | - | +---------------+ +---------------+ | | - | | logical port 0| | logical port 1| | | - +---+---------------+-----------+---------------+---+ __| - ^ : - | | - : v __ - +---+---------------+----------+---------------+---+ | - | | logical port 0| | logical port 1| | | - | +---------------+ +---------------+ | | - | ^ : | | - | | | | | Host - | : v | | - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>Physical port to virtual switch to VNF to virtual switch - to VNF to virtual switch to physical port</preamble> - - <artwork><![CDATA[ __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | ^ | | | ^ | | | - | | v | | | v | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 1 | | | | 0 1 | | | - +---+---------------+--+ +---+---------------+--+__| - ^ : ^ : - | | | | - : v : v _ - +---+---------------+---------+---------------+--+ | - | | 0 1 | | 3 4 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | ^ | ^ | | | Host - | | |-----------------| v | | - | +--------------+ +--------------+ | | - | | phy ports | vSwitch | phy ports | | | - +---+--------------+----------+--------------+---+_| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>Physical port to virtual switch to VNF</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ | | - | | | | Guest - | : | | - | +---------------+ | | - | | logical port 0| | | - +---+---------------+-------------------------------+ __| - ^ - | - : __ - +---+---------------+------------------------------+ | - | | logical port 0| | | - | +---------------+ | | - | ^ | | - | | | | Host - | : | | - | +--------------+ | | - | | phy port | vSwitch | | - +---+--------------+------------ -------------- ---+ __| - ^ - | - : - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>VNF to virtual switch to physical port</preamble> - - <artwork><![CDATA[ __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | : | | - | | | | Guest - | v | | - | +---------------+ | | - | | logical port | | | - +-------------------------------+---------------+---+ __| - : - | - v __ - +------------------------------+---------------+---+ | - | | logical port | | | - | +---------------+ | | - | : | | - | | | | Host - | v | | - | +--------------+ | | - | vSwitch | phy port | | | - +-------------------------------+--------------+---+ __| - : - | - v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+]]></artwork> - </figure><figure> - <preamble>VNF to virtual switch to VNF</preamble> - - <artwork><![CDATA[ __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | | | | ^ | | - | v | | | | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 | | | | 0 | | | - +---+---------------+--+ +---+---------------+--+__| - : ^ - | | - v : _ - +---+---------------+---------+---------------+--+ | - | | 1 | | 1 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | | ^ | | Host - | L-----------------+ | | - | | | - | vSwitch | | - +------------------------------------------------+_|]]></artwork> - </figure></t> - - <t>A set of Deployment Scenario figures is available on the VSPERF Test - Methodology Wiki page <xref target="TestTopo"/>.</t> - </section> - - <section title="3x3 Matrix Coverage"> - <t>This section organizes the many existing test specifications into the - "3x3" matrix (introduced in <xref target="I-D.ietf-bmwg-virtual-net"/>). - Because the LTD specification ID names are quite long, this section is - organized into lists for each occupied cell of the matrix (not all are - occupied, also the matrix has grown to 3x4 to accommodate scale metrics - when displaying the coverage of many metrics/benchmarks). The current - version of the LTD specification is available <xref target="LTD"/>.</t> - - <t>The tests listed below assess the activation of paths in the data - plane, rather than the control plane.</t> - - <t>A complete list of tests with short summaries is available on the - VSPERF "LTD Test Spec Overview" Wiki page <xref target="LTDoverV"/>.</t> - - <section title="Speed of Activation"> - <t><list style="symbols"> - <t>Activation.RFC2889.AddressLearningRate</t> - - <t>PacketLatency.InitialPacketProcessingLatency</t> - </list></t> - </section> - - <section title="Accuracy of Activation section"> - <t><list style="symbols"> - <t>CPDP.Coupling.Flow.Addition</t> - </list></t> - </section> - - <section title="Reliability of Activation"> - <t><list style="symbols"> - <t>Throughput.RFC2544.SystemRecoveryTime</t> - - <t>Throughput.RFC2544.ResetTime</t> - </list></t> - </section> - - <section title="Scale of Activation"> - <t><list style="symbols"> - <t>Activation.RFC2889.AddressCachingCapacity</t> - </list></t> - </section> - - <section title="Speed of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2544.PacketLossRate</t> - - <t>CPU.RFC2544.0PacketLoss</t> - - <t>Throughput.RFC2544.PacketLossRateFrameModification</t> - - <t>Throughput.RFC2544.BackToBackFrames</t> - - <t>Throughput.RFC2889.MaxForwardingRate</t> - - <t>Throughput.RFC2889.ForwardPressure</t> - - <t>Throughput.RFC2889.BroadcastFrameForwarding</t> - </list></t> - </section> - - <section title="Accuracy of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2889.ErrorFramesFiltering</t> - - <t>Throughput.RFC2544.Profile</t> - </list></t> - </section> - - <section title="Reliability of Operation"> - <t><list style="symbols"> - <t>Throughput.RFC2889.Soak</t> - - <t>Throughput.RFC2889.SoakFrameModification</t> - - <t>PacketDelayVariation.RFC3393.Soak</t> - </list></t> - </section> - - <section title="Scalability of Operation"> - <t><list style="symbols"> - <t>Scalability.RFC2544.0PacketLoss</t> - - <t>MemoryBandwidth.RFC2544.0PacketLoss.Scalability</t> - </list></t> - </section> - - <section title="Summary"> - <t><figure> - <artwork><![CDATA[|------------------------------------------------------------------------| -| | | | | | -| | SPEED | ACCURACY | RELIABILITY | SCALE | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Activation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Operation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| De-activation | | | | | -| | | | | | -|------------------------------------------------------------------------|]]></artwork> - </figure></t> - </section> - </section> - - <section title="Security Considerations"> - <t>Benchmarking activities as described in this memo are limited to - technology characterization of a Device Under Test/System Under Test - (DUT/SUT) using controlled stimuli in a laboratory environment, with - dedicated address space and the constraints specified in the sections - above.</t> - - <t>The benchmarking network topology will be an independent test setup - and MUST NOT be connected to devices that may forward the test traffic - into a production network, or misroute traffic to the test management - network.</t> - - <t>Further, benchmarking is performed on a "black-box" basis, relying - solely on measurements observable external to the DUT/SUT.</t> - - <t>Special capabilities SHOULD NOT exist in the DUT/SUT specifically for - benchmarking purposes. Any implications for network security arising - from the DUT/SUT SHOULD be identical in the lab and in production - networks.</t> - </section> - - <section anchor="IANA" title="IANA Considerations"> - <t>No IANA Action is requested at this time.</t> - </section> - - <section title="Acknowledgements"> - <t>The authors appreciate and acknowledge comments from Scott Bradner, - Marius Georgescu, Ramki Krishnan, Doug Montgomery, Martin Klozik, - Christian Trautman, and others for their reviews.</t> - </section> - </middle> - - <back> - <references title="Normative References"> - <?rfc ?> - - <?rfc include="reference.RFC.2119"?> - - <?rfc ?> - - <?rfc include="reference.RFC.2330"?> - - <?rfc include='reference.RFC.2544'?> - - <?rfc include="reference.RFC.2679"?> - - <?rfc include='reference.RFC.2680'?> - - <?rfc include='reference.RFC.3393'?> - - <?rfc include='reference.RFC.3432'?> - - <?rfc include='reference.RFC.2681'?> - - <?rfc include='reference.RFC.5905'?> - - <?rfc include='reference.RFC.4689'?> - - <?rfc include='reference.RFC.4737'?> - - <?rfc include='reference.RFC.5357'?> - - <?rfc include='reference.RFC.2889'?> - - <?rfc include='reference.RFC.3918'?> - - <?rfc include='reference.RFC.6201'?> - - <?rfc include='reference.RFC.2285'?> - - <reference anchor="NFV.PER001"> - <front> - <title>Network Function Virtualization: Performance and Portability - Best Practices</title> - - <author fullname="ETSI NFV" initials="" surname=""> - <organization/> - </author> - - <date month="June" year="2014"/> - </front> - - <seriesInfo name="Group Specification" - value="ETSI GS NFV-PER 001 V1.1.1 (2014-06)"/> - - <format type="PDF"/> - </reference> - </references> - - <references title="Informative References"> - <?rfc include='reference.RFC.1242'?> - - <?rfc include='reference.RFC.5481'?> - - <?rfc include='reference.RFC.6049'?> - - <?rfc include='reference.RFC.6248'?> - - <?rfc include='reference.RFC.6390'?> - - <?rfc include='reference.I-D.ietf-bmwg-virtual-net'?> - - <?rfc include='reference.I-D.huang-bmwg-virtual-network-performance'?> - - <reference anchor="TestTopo"> - <front> - <title>Test Topologies - https://wiki.opnfv.org/vsperf/test_methodology</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="LTDoverV"> - <front> - <title>LTD Test Spec Overview - https://wiki.opnfv.org/wiki/vswitchperf_test_spec_review</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="LTD"> - <front> - <title>LTD Test Specification - http://artifacts.opnfv.org/vswitchperf/docs/requirements/index.html</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="BrahRel"> - <front> - <title>Brahmaputra, Second OPNFV Release - https://www.opnfv.org/brahmaputra</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - - <reference anchor="IFA003"> - <front> - <title>https://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA003_Acceleration_-_vSwitch_Spec/</title> - - <author> - <organization/> - </author> - - <date/> - </front> - </reference> - </references> - </back> -</rfc> diff --git a/docs/testing/developer/devguide/requirements/ietf_draft/rfc8204-vsperf-bmwg-vswitch-opnfv.rst b/docs/testing/developer/devguide/requirements/ietf_draft/rfc8204-vsperf-bmwg-vswitch-opnfv.rst new file mode 100644 index 00000000..ee7f98b5 --- /dev/null +++ b/docs/testing/developer/devguide/requirements/ietf_draft/rfc8204-vsperf-bmwg-vswitch-opnfv.rst @@ -0,0 +1,19 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV, Intel Corporation, AT&T, Red Hat, Spirent, Ixia and others. + +*************************************** +IETF benchmarking specification RFC8204 +*************************************** + +The directory /ietf_draft was used to store draft versions of the VSPERF test specification proposed +as an Internet Draft and subsequently approved for publication as RFC8204. The draft versions have +been removed. "Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV)" is an +informational RFC published by the IETF available here https://tools.ietf.org/html/rfc8204. + +For more information about VSPERF refer to: + +* Wiki: https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases +* Repository: https://git.opnfv.org/vswitchperf +* Artifacts: https://artifacts.opnfv.org/vswitchperf.html +* Continuous Integration: https://build.opnfv.org/ci/view/vswitchperf/ diff --git a/docs/testing/developer/devguide/results/scenario.rst b/docs/testing/developer/devguide/results/scenario.rst index a57d6a03..dbdc7877 100644 --- a/docs/testing/developer/devguide/results/scenario.rst +++ b/docs/testing/developer/devguide/results/scenario.rst @@ -5,7 +5,7 @@ VSPERF Test Scenarios ===================== -Predefined Tests run with CI: +Predefined Tests suitable for automated execution with CI: ===================== =========================================================== Test Definition @@ -45,3 +45,4 @@ Supported traffic generators: * Xena * MoonGen * Dummy +* T-Rex diff --git a/docs/testing/user/configguide/index.rst b/docs/testing/user/configguide/index.rst index 8c9db1aa..83908a97 100644 --- a/docs/testing/user/configguide/index.rst +++ b/docs/testing/user/configguide/index.rst @@ -14,13 +14,13 @@ Introduction VSPERF is an OPNFV testing project. -VSPERF is an OPNFV project that provides an automated test-framework and comprehensive test suite based on Industry +VSPERF provides an automated test-framework and comprehensive test suite based on Industry Test Specifications for measuring NFVI data-plane performance. The data-path includes switching technologies with physical and virtual network interfaces. The VSPERF architecture is switch and traffic generator agnostic and test -cases can be easily customized. Software versions and configurations including the vSwitch (OVS or VPP) as well as -the network topology are controlled by VSPERF (independent of OpenStack). VSPERF is used as a development tool for -optimizing switching technologies, qualification of packet processing components and for pre-deployment evaluation -of the NFV platform data-path. +cases can be easily customized. VSPERF was designed to be independent of OpenStack therefore OPNFV installer scenarios +are not required. VSPERF can source, configure and deploy the device-under-test using specified software versions and +network topology. VSPERF is used as a development tool for optimizing switching technologies, qualification of packet +processing functions and for evaluation of data-path performance. The Euphrates release adds new features and improvements that will help advance high performance packet processing on Telco NFV platforms. This includes new test cases, flexibility in customizing test-cases, new results display diff --git a/docs/testing/user/configguide/installation.rst b/docs/testing/user/configguide/installation.rst index 0a98c945..8bad4efd 100644 --- a/docs/testing/user/configguide/installation.rst +++ b/docs/testing/user/configguide/installation.rst @@ -63,6 +63,7 @@ The vSwitch must support Open Flow 1.3 or greater. * Open vSwitch * Open vSwitch with DPDK support * TestPMD application from DPDK (supports p2p and pvp scenarios) +* Cisco VPP Supported Hypervisors --------------------- @@ -342,7 +343,7 @@ following location: http://www.tuned-project.org/2017/04/27/tuned-2-8-0-released/ -Follow instructions to install the latest tuned-adm onto your system. For +Follow the instructions to install the latest tuned-adm onto your system. For current RHEL customers you should already have the most current version. You just need to install the cpu-partitioning profile. diff --git a/docs/testing/user/configguide/trafficgen.rst b/docs/testing/user/configguide/trafficgen.rst index 7c14c55d..4b9eec6e 100644 --- a/docs/testing/user/configguide/trafficgen.rst +++ b/docs/testing/user/configguide/trafficgen.rst @@ -248,7 +248,7 @@ Ixia ---- VSPERF can use both IxNetwork and IxExplorer TCL servers to control Ixia chassis. -However usage of IxNetwork TCL server is a preferred option. Following sections +However, usage of IxNetwork TCL server is a preferred option. The following sections will describe installation and configuration of IxNetwork components used by VSPERF. Installation @@ -675,11 +675,15 @@ https://github.com/emmericp/MoonGen For VSPERF use, MoonGen should be cloned from here (as opposed to the previously mentioned GitHub): -git clone https://github.com/atheurer/lua-trafficgen +.. code-block:: console + + git clone https://github.com/atheurer/lua-trafficgen and use the master branch: -git checkout master +.. code-block:: console + + git checkout master VSPERF uses a particular Lua script with the MoonGen project: @@ -808,10 +812,10 @@ Example of this configuration is in conf/03_traffic.conf or conf/10_custom.conf. TRAFFICGEN_TREX_USER = '' TRAFFICGEN_TREX_BASE_DIR = '' -TRAFFICGEN_TREX_USER has to have sudo permission and passwordless access. +TRAFFICGEN_TREX_USER has to have sudo permission and password-less access. TRAFFICGEN_TREX_BASE_DIR is the place, where is stored 't-rex-64' file. -It is possible to specify the accurancy of RFC2544 Throughput measurement. +It is possible to specify the accuracy of RFC2544 Throughput measurement. Threshold below defines maximal difference between frame rate of successful (i.e. defined frameloss was reached) and unsuccessful (i.e. frameloss was exceeded) iterations. @@ -821,3 +825,18 @@ Default value of this parameter is defined in conf/03_traffic.conf as follows: .. code-block:: console TRAFFICGEN_TREX_RFC2544_TPUT_THRESHOLD = '' + +SR-IOV and Multistream layer 2 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +T-Rex by default only accepts packets on the receive side if the destination mac matches the +MAC address specified in the /etc/trex-cfg.yaml on the server side. For SR-IOV this creates +challenges with modifying the MAC address in the traffic profile to correctly flow packets +through specified VFs. To remove this limitation enable promiscuous mode on T-Rex to allow +all packets regardless of the destination mac to be accepted. + +This also creates problems when doing multistream at layer 2 since the source macs will be +modified. Enable Promiscuous mode when doing multistream at layer 2 testing with T-Rex. + +.. code-block:: console + + TRAFFICGEN_TREX_PROMISCUOUS=True diff --git a/docs/testing/user/configguide/upgrade.rst b/docs/testing/user/configguide/upgrade.rst index cf92572c..a41683ee 100644 --- a/docs/testing/user/configguide/upgrade.rst +++ b/docs/testing/user/configguide/upgrade.rst @@ -35,6 +35,7 @@ List of stable releases: colorado.2.0 colorado.3.0 danube.1.0 + euphrates.1.0 You could select which stable release should be used. For example, select ``danube.1.0``: @@ -180,4 +181,3 @@ parameters and update them according to the documentation: rfc2544_tests stream_type traffic_type - diff --git a/docs/testing/user/userguide/integration.rst b/docs/testing/user/userguide/integration.rst index 83b29da6..249a03c4 100644 --- a/docs/testing/user/userguide/integration.rst +++ b/docs/testing/user/userguide/integration.rst @@ -457,7 +457,7 @@ To run GENEVE decapsulation tests: Executing Tunnel encapsulation+decapsulation tests -------------------------------------------------- -The OVS DPDK encapsulation_decapsulation tests requires IPs, MAC addresses, +The OVS DPDK encapsulation/decapsulation tests requires IPs, MAC addresses, bridge names and WHITELIST_NICS for DPDK. The test cases can test the tunneling encap and decap without using any ingress diff --git a/docs/testing/user/userguide/testusage.rst b/docs/testing/user/userguide/testusage.rst index 4d3528d0..20c30a40 100644 --- a/docs/testing/user/userguide/testusage.rst +++ b/docs/testing/user/userguide/testusage.rst @@ -20,6 +20,8 @@ support in VSPERF includes: Traffic generator modules. - Moongen software traffic generator. Requires a separate machine running moongen to execute packet generation. +- T-Rex software traffic generator. Requires a separate machine running T-Rex + Server to execute packet generation. If you want to use another traffic generator, please select the :ref:`trafficgen-dummy` generator. @@ -475,7 +477,7 @@ For example: * vSwitch tests with DPDK or without DPDK support to verify impact of VF usage on vSwitch performance -* tests without vSwitch, where traffic is forwared directly +* tests without vSwitch, where traffic is forwarded directly between VF interfaces by packet forwarder (e.g. testpmd application) * tests without vSwitch, where VM accesses VF interfaces directly by PCI-passthrough_ to measure raw VM throughput performance. @@ -486,11 +488,11 @@ Using QEMU with PCI passthrough support ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Raw virtual machine throughput performance can be measured by execution of PVP -test with direct access to NICs by PCI passthrough. To execute VM with direct +test with direct access to NICs by PCI pass-through. To execute VM with direct access to PCI devices, enable vfio-pci_. In order to use virtual functions, SRIOV-support_ must be enabled. -Execution of test with PCI passthrough with vswitch disabled: +Execution of test with PCI pass-through with vswitch disabled: .. code-block:: console @@ -498,9 +500,9 @@ Execution of test with PCI passthrough with vswitch disabled: --vswitch none --vnf QemuPciPassthrough pvp_tput Any of supported guest-loopback-application_ can be used inside VM with -PCI passthrough support. +PCI pass-through support. -Note: Qemu with PCI passthrough support can be used only with PVP test +Note: Qemu with PCI pass-through support can be used only with PVP test deployment. .. _guest-loopback-application: diff --git a/tools/pkt_gen/trex/trex.py b/tools/pkt_gen/trex/trex.py index 7cdeec9c..abae35dc 100644 --- a/tools/pkt_gen/trex/trex.py +++ b/tools/pkt_gen/trex/trex.py @@ -21,6 +21,7 @@ import subprocess import sys from collections import OrderedDict # pylint: disable=unused-import +import netaddr import zmq from conf import settings from conf import merge_spec @@ -174,8 +175,46 @@ class Trex(ITrafficGenerator): fsize_no_fcs = frame_size - 4 payload_a = max(0, fsize_no_fcs - len(base_pkt_a)) * 'x' payload_b = max(0, fsize_no_fcs - len(base_pkt_b)) * 'x' - pkt_a = STLPktBuilder(pkt=base_pkt_a/payload_a) - pkt_b = STLPktBuilder(pkt=base_pkt_b/payload_b) + + # Multistream configuration, increments source values only + ms_mod = list() # mod list for incrementing values to be populated based on layer + if traffic['multistream'] > 1: + if traffic['stream_type'].upper() == 'L2': + for _ in [base_pkt_a, base_pkt_b]: + ms_mod += [STLVmFlowVar(name="mac_start", min_value=0, + max_value=traffic['multistream'] - 1, size=4, op="inc"), + STLVmWrFlowVar(fv_name="mac_start", pkt_offset=7)] + elif traffic['stream_type'].upper() == 'L3': + ip_src = {"start": int(netaddr.IPAddress(traffic['l3']['srcip'])), + "end": int(netaddr.IPAddress(traffic['l3']['srcip'])) + traffic['multistream'] - 1} + ip_dst = {"start": int(netaddr.IPAddress(traffic['l3']['dstip'])), + "end": int(netaddr.IPAddress(traffic['l3']['dstip'])) + traffic['multistream'] - 1} + for ip_address in [ip_src, ip_dst]: + ms_mod += [STLVmFlowVar(name="ip_src", min_value=ip_address['start'], + max_value=ip_address['end'], size=4, op="inc"), + STLVmWrFlowVar(fv_name="ip_src", pkt_offset="IP.src")] + elif traffic['stream_type'].upper() == 'L4': + for udpport in [traffic['l4']['srcport'], traffic['l4']['dstport']]: + if udpport + (traffic['multistream'] - 1) > 65535: + start_port = udpport + # find the max/min port number based on the loop around of 65535 to 0 if needed + minimum_value = 65535 - (traffic['multistream'] -1) + maximum_value = 65535 + else: + start_port, minimum_value = udpport, udpport + maximum_value = start_port + (traffic['multistream'] - 1) + ms_mod += [STLVmFlowVar(name="port_src", init_value=start_port, + min_value=minimum_value, max_value=maximum_value, + size=2, op="inc"), + STLVmWrFlowVar(fv_name="port_src", pkt_offset="UDP.sport"),] + + if ms_mod: # multistream detected + pkt_a = STLPktBuilder(pkt=base_pkt_a/payload_a, vm=[ms_mod[0], ms_mod[1]]) + pkt_b = STLPktBuilder(pkt=base_pkt_b/payload_b, vm=[ms_mod[2], ms_mod[3]]) + else: + pkt_a = STLPktBuilder(pkt=base_pkt_a / payload_a) + pkt_b = STLPktBuilder(pkt=base_pkt_b / payload_b) + stream_1 = STLStream(packet=pkt_a, name='stream_1', mode=STLTXCont(percentage=traffic['frame_rate'])) @@ -201,6 +240,10 @@ class Trex(ITrafficGenerator): my_ports = [0, 1] self._stlclient.reset(my_ports) ports_info = self._stlclient.get_port_info(my_ports) + # for SR-IOV + if settings.getValue('TRAFFICGEN_TREX_PROMISCUOUS'): + self._stlclient.set_port_attr(my_ports, promiscuous=True) + packet_1, packet_2 = Trex.create_packets(traffic, ports_info) stream_1, stream_2, stream_1_lat, stream_2_lat = Trex.create_streams(packet_1, packet_2, traffic) self._stlclient.add_streams(stream_1, ports=[0]) diff --git a/vswitches/vpp_dpdk_vhost.py b/vswitches/vpp_dpdk_vhost.py index 2ac70a1a..bb472788 100644 --- a/vswitches/vpp_dpdk_vhost.py +++ b/vswitches/vpp_dpdk_vhost.py @@ -71,8 +71,14 @@ class VppDpdkVhost(IVSwitch, tasks.Process): # configure path to the plugins tmp_args['plugin_path'] = S.getValue('TOOLS')['vpp_plugin_path'] + mqs = int(S.getValue('VSWITCH_DPDK_MULTI_QUEUES')) + tmp_rxqs = '' + if mqs: + tmp_rxqs = " {{ num-rx-queues {} }}".format(mqs) + + # configure physical ports for nic in S.getValue('NICS'): - tmp_args['dpdk'].append("dev {}".format(nic['pci'])) + tmp_args['dpdk'].append("dev {}{}".format(nic['pci'], tmp_rxqs)) self._vswitch_args = self._process_vpp_args(tmp_args) def _get_nic_info(self, key='Name'): |