docs/requirements/vswitchperf_ltp.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3 .. (c) OPNFV, Intel Corporation, AT&T and others.
   4
   5 .. 3.1
   6
   7 *****************************
   8 VSPERF LEVEL TEST PLAN (LTP)
   9 *****************************
  10
  11 ===============
  12 Introduction
  13 ===============
  14
  15 The objective of the OPNFV project titled
  16 **Characterize vSwitch Performance for Telco NFV Use Cases**, is to
  17 evaluate the performance of virtual switches to identify its suitability for a
  18 Telco Network Function Virtualization (NFV) environment. The intention of this
  19 Level Test Plan (LTP) document is to specify the scope, approach, resources,
  20 and schedule of the virtual switch performance benchmarking activities in
  21 OPNFV. The test cases will be identified in a separate document called the
  22 Level Test Design (LTD) document.
  23
  24 This document is currently in draft form.
  25
  26 .. 3.1.1
  27
  28
  29 .. _doc-id:
  30
  31 Document identifier
  32 =========================
  33
  34 The document id will be used to uniquely identify versions of the LTP. The
  35 format for the document id will be: OPNFV\_vswitchperf\_LTP\_REL\_STATUS, where
  36 by the status is one of: draft, reviewed, corrected or final. The document id
  37 for this version of the LTP is: OPNFV\_vswitchperf\_LTP\_Colorado\_REVIEWED.
  38
  39 .. 3.1.2
  40
  41 .. _scope:
  42
  43 Scope
  44 ==========
  45
  46 The main purpose of this project is to specify a suite of
  47 performance tests in order to objectively measure the current packet
  48 transfer characteristics of a virtual switch in the NFVI. The intent of
  49 the project is to facilitate the performance testing of any virtual switch.
  50 Thus, a generic suite of tests shall be developed, with no hard dependencies to
  51 a single implementation. In addition, the test case suite shall be
  52 architecture independent.
  53
  54 The test cases developed in this project shall not form part of a
  55 separate test framework, all of these tests may be inserted into the
  56 Continuous Integration Test Framework and/or the Platform Functionality
  57 Test Framework - if a vSwitch becomes a standard component of an OPNFV
  58 release.
  59
  60 .. 3.1.3
  61
  62 References
  63 ===============
  64
  65 *  `RFC 1242 Benchmarking Terminology for Network Interconnection
  66    Devices <http://www.ietf.org/rfc/rfc1242.txt>`__
  67 *  `RFC 2544 Benchmarking Methodology for Network Interconnect
  68    Devices <http://www.ietf.org/rfc/rfc2544.txt>`__
  69 *  `RFC 2285 Benchmarking Terminology for LAN Switching
  70    Devices <http://www.ietf.org/rfc/rfc2285.txt>`__
  71 *  `RFC 2889 Benchmarking Methodology for LAN Switching
  72    Devices <http://www.ietf.org/rfc/rfc2889.txt>`__
  73 *  `RFC 3918 Methodology for IP Multicast
  74    Benchmarking <http://www.ietf.org/rfc/rfc3918.txt>`__
  75 *  `RFC 4737 Packet Reordering
  76    Metrics <http://www.ietf.org/rfc/rfc4737.txt>`__
  77 *  `RFC 5481 Packet Delay Variation Applicability
  78    Statement <http://www.ietf.org/rfc/rfc5481.txt>`__
  79 *  `RFC 6201 Device Reset
  80    Characterization <http://tools.ietf.org/html/rfc6201>`__
  81
  82 .. 3.1.4
  83
  84 Level in the overall sequence
  85 ===============================
  86 The level of testing conducted by vswitchperf in the overall testing sequence (among
  87 all the testing projects in OPNFV) is the performance benchmarking of a
  88 specific component (the vswitch) in the OPNFV platfrom. It's expected that this
  89 testing will follow on from the functional and integration testing conducted by
  90 other testing projects in OPNFV, namely Functest and Yardstick.
  91
  92 .. 3.1.5
  93
  94 Test classes and overall test conditions
  95 =========================================
  96 A benchmark is defined by the IETF as: A standardized test that serves as a
  97 basis for performance evaluation and comparison. It's important to note that
  98 benchmarks are not Functional tests. They do not provide PASS/FAIL criteria,
  99 and most importantly ARE NOT performed on live networks, or performed with live
 100 network traffic.
 101
 102 In order to determine the packet transfer characteristics of a virtual switch,
 103 the benchmarking tests will be broken down into the following categories:
 104
 105 - **Throughput Tests** to measure the maximum forwarding rate (in
 106   frames per second or fps) and bit rate (in Mbps) for a constant load
 107   (as defined by `RFC1242 <https://www.rfc-editor.org/rfc/rfc1242.txt>`__)
 108   without traffic loss.
 109 - **Packet and Frame Delay Tests** to measure average, min and max
 110   packet and frame delay for constant loads.
 111 - **Stream Performance Tests** (TCP, UDP) to measure bulk data transfer
 112   performance, i.e. how fast systems can send and receive data through
 113   the virtual switch.
 114 - **Request/Response Performance** Tests (TCP, UDP) the measure the
 115   transaction rate through the virtual switch.
 116 - **Packet Delay Tests** to understand latency distribution for
 117   different packet sizes and over an extended test run to uncover
 118   outliers.
 119 - **Scalability Tests** to understand how the virtual switch performs
 120   as the number of flows, active ports, complexity of the forwarding
 121   logic's configuration... it has to deal with increases.
 122 - **Control Path and Datapath Coupling** Tests, to understand how
 123   closely coupled the datapath and the control path are as well as the
 124   effect of this coupling on the performance of the DUT.
 125 - **CPU and Memory Consumption Tests** to understand the virtual
 126   switch’s footprint on the system, this includes:
 127
 128   * CPU core utilization.
 129   * CPU cache utilization.
 130   * Memory footprint.
 131   * System bus (QPI, PCI, ..) utilization.
 132   * Memory lanes utilization.
 133   * CPU cycles consumed per packet.
 134   * Time To Establish Flows Tests.
 135
 136 - **Noisy Neighbour Tests**, to understand the effects of resource
 137   sharing on the performance of a virtual switch.
 138
 139 **Note:** some of the tests above can be conducted simultaneously where
 140 the combined results would be insightful, for example Packet/Frame Delay
 141 and Scalability.
 142
 143
 144
 145 .. 3.2
 146
 147 .. _details-of-LTP:
 148
 149 ===================================
 150 Details of the Level Test Plan
 151 ===================================
 152
 153 This section describes the following items:
 154 * Test items and their identifiers (TestItems_)
 155 * Test Traceability Matrix (TestMatrix_)
 156 * Features to be tested (FeaturesToBeTested_)
 157 * Features not to be tested (FeaturesNotToBeTested_)
 158 * Approach (Approach_)
 159 * Item pass/fail criteria (PassFailCriteria_)
 160 * Suspension criteria and resumption requirements (SuspensionResumptionReqs_)
 161
 162 .. 3.2.1
 163
 164 .. _TestItems:
 165
 166 Test items and their identifiers
 167 ==================================
 168 The test item/application vsperf is trying to test are virtual switches and in
 169 particular their performance in an nfv environment. vsperf will first try to
 170 measure the maximum achievable performance by a virtual switch and then it will
 171 focus in on usecases that are as close to real life deployment scenarios as
 172 possible.
 173
 174 .. 3.2.2
 175
 176 .. _TestMatrix:
 177
 178 Test Traceability Matrix
 179 ==========================
 180 vswitchperf leverages the "3x3" matrix (introduced in
 181 https://tools.ietf.org/html/draft-ietf-bmwg-virtual-net-02) to achieve test
 182 traceability. The matrix was expanded to 3x4 to accommodate scale metrics when
 183 displaying the coverage of many metrics/benchmarks). Test case covreage in the
 184 LTD is tracked using the following catagories:
 185
 186
 187 +---------------+-------------+------------+---------------+-------------+
 188 |               |             |            |               |             |
 189 |               |   SPEED     |  ACCURACY  |  RELIABILITY  |    SCALE    |
 190 |               |             |            |               |             |
 191 +---------------+-------------+------------+---------------+-------------+
 192 |               |             |            |               |             |
 193 |  Activation   |      X      |     X      |       X       |      X      |
 194 |               |             |            |               |             |
 195 +---------------+-------------+------------+---------------+-------------+
 196 |               |             |            |               |             |
 197 |  Operation    |      X      |      X     |       X       |      X      |
 198 |               |             |            |               |             |
 199 +---------------+-------------+------------+---------------+-------------+
 200 |               |             |            |               |             |
 201 | De-activation |             |            |               |             |
 202 |               |             |            |               |             |
 203 +---------------+-------------+------------+---------------+-------------+
 204
 205 X = denotes a test catagory that has 1 or more test cases defined.
 206
 207 .. 3.2.3
 208
 209 .. _FeaturesToBeTested:
 210
 211 Features to be tested
 212 ==========================
 213
 214 Characterizing virtual switches (i.e. Device Under Test (DUT) in this document)
 215 includes measuring the following performance metrics:
 216
 217 - **Throughput** as defined by `RFC1242
 218   <https://www.rfc-editor.org/rfc/rfc1242.txt>`__: The maximum rate at which
 219   **none** of the offered frames are dropped by the DUT. The maximum frame
 220   rate and bit rate that can be transmitted by the DUT without any error
 221   should be recorded. Note there is an equivalent bit rate and a specific
 222   layer at which the payloads contribute to the bits. Errors and
 223   improperly formed frames or packets are dropped.
 224 - **Packet delay** introduced by the DUT and its cumulative effect on
 225   E2E networks. Frame delay can be measured equivalently.
 226 - **Packet delay variation**: measured from the perspective of the
 227   VNF/application. Packet delay variation is sometimes called "jitter".
 228   However, we will avoid the term "jitter" as the term holds different
 229   meaning to different groups of people. In this document we will
 230   simply use the term packet delay variation. The preferred form for this
 231   metric is the PDV form of delay variation defined in `RFC5481
 232   <https://www.rfc-editor.org/rfc/rfc5481.txt>`__. The most relevant
 233   measurement of PDV considers the delay variation of a single user flow,
 234   as this will be relevant to the size of end-system buffers to compensate
 235   for delay variation. The measurement system's ability to store the
 236   delays of individual packets in the flow of interest is a key factor
 237   that determines the specific measurement method. At the outset, it is
 238   ideal to view the complete PDV distribution. Systems that can capture
 239   and store packets and their delays have the freedom to calculate the
 240   reference minimum delay and to determine various quantiles of the PDV
 241   distribution accurately (in post-measurement processing routines).
 242   Systems without storage must apply algorithms to calculate delay and
 243   statistical measurements on the fly. For example, a system may store
 244   temporary estimates of the mimimum delay and the set of (100) packets
 245   with the longest delays during measurement (to calculate a high quantile,
 246   and update these sets with new values periodically.
 247   In some cases, a limited number of delay histogram bins will be
 248   available, and the bin limits will need to be set using results from
 249   repeated experiments. See section 8 of `RFC5481
 250   <https://www.rfc-editor.org/rfc/rfc5481.txt>`__.
 251 - **Packet loss** (within a configured waiting time at the receiver): All
 252   packets sent to the DUT should be accounted for.
 253 - **Burst behaviour**: measures the ability of the DUT to buffer packets.
 254 - **Packet re-ordering**: measures the ability of the device under test to
 255   maintain sending order throughout transfer to the destination.
 256 - **Packet correctness**: packets or Frames must be well-formed, in that
 257   they include all required fields, conform to length requirements, pass
 258   integrity checks, etc.
 259 - **Availability and capacity** of the DUT i.e. when the DUT is fully “up”
 260   and connected, following measurements should be captured for
 261   DUT without any network packet load:
 262
 263   - Includes average power consumption of the CPUs (in various power states) and
 264     system over specified period of time. Time period should not be less
 265     than 60 seconds.
 266   - Includes average per core CPU utilization over specified period of time.
 267     Time period should not be less than 60 seconds.
 268   - Includes the number of NIC interfaces supported.
 269   - Includes headroom of VM workload processing cores (i.e. available
 270     for applications).
 271
 272 .. 3.2.4
 273
 274 .. _FeaturesNotToBeTested:
 275
 276 Features not to be tested
 277 ==========================
 278 vsperf doesn't intend to define or perform any functional tests. The aim is to
 279 focus on performance.
 280
 281 .. 3.2.5
 282
 283 .. _Approach:
 284
 285 Approach
 286 ==============
 287 The testing approach adoped by the vswitchperf project is black box testing,
 288 meaning the test inputs can be generated and the outputs captured and
 289 completely evaluated from the outside of the System Under Test. Some metrics
 290 can be collected on the SUT, such as cpu or memory utilization if the
 291 collection has no/minimal impact on benchmark.
 292 This section will look at the deployment scenarios and the general methodology
 293 used by vswitchperf. In addition, this section will also specify the details of
 294 the Test Report that must be collected for each of the test cases.
 295
 296 .. 3.2.5.1
 297
 298 Deployment Scenarios
 299 --------------------------
 300 The following represents possible deployment test scenarios which can
 301 help to determine the performance of both the virtual switch and the
 302 datapaths to physical ports (to NICs) and to logical ports (to VNFs):
 303
 304 .. 3.2.5.1.1
 305
 306 Physical port → vSwitch → physical port
 307 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 308 .. code-block:: console
 309
 310                                                             _
 311        +--------------------------------------------------+  |
 312        |              +--------------------+              |  |
 313        |              |                    |              |  |
 314        |              |                    v              |  |  Host
 315        |   +--------------+            +--------------+   |  |
 316        |   |   phy port   |  vSwitch   |   phy port   |   |  |
 317        +---+--------------+------------+--------------+---+ _|
 318                   ^                           :
 319                   |                           |
 320                   :                           v
 321        +--------------------------------------------------+
 322        |                                                  |
 323        |                traffic generator                 |
 324        |                                                  |
 325        +--------------------------------------------------+
 326
 327 .. 3.2.5.1.2
 328
 329 Physical port → vSwitch → VNF → vSwitch → physical port
 330 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 331 .. code-block:: console
 332
 333                                                              _
 334        +---------------------------------------------------+  |
 335        |                                                   |  |
 336        |   +-------------------------------------------+   |  |
 337        |   |                 Application               |   |  |
 338        |   +-------------------------------------------+   |  |
 339        |       ^                                  :        |  |
 340        |       |                                  |        |  |  Guest
 341        |       :                                  v        |  |
 342        |   +---------------+           +---------------+   |  |
 343        |   | logical port 0|           | logical port 1|   |  |
 344        +---+---------------+-----------+---------------+---+ _|
 345                ^                                  :
 346                |                                  |
 347                :                                  v         _
 348        +---+---------------+----------+---------------+---+  |
 349        |   | logical port 0|          | logical port 1|   |  |
 350        |   +---------------+          +---------------+   |  |
 351        |       ^                                  :       |  |
 352        |       |                                  |       |  |  Host
 353        |       :                                  v       |  |
 354        |   +--------------+            +--------------+   |  |
 355        |   |   phy port   |  vSwitch   |   phy port   |   |  |
 356        +---+--------------+------------+--------------+---+ _|
 357                   ^                           :
 358                   |                           |
 359                   :                           v
 360        +--------------------------------------------------+
 361        |                                                  |
 362        |                traffic generator                 |
 363        |                                                  |
 364        +--------------------------------------------------+
 365
 366 .. 3.2.5.1.3
 367
 368 Physical port → vSwitch → VNF → vSwitch → VNF → vSwitch → physical port
 369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 370
 371 .. code-block:: console
 372
 373                                                        _
 374     +----------------------+  +----------------------+  |
 375     |   Guest 1            |  |   Guest 2            |  |
 376     |   +---------------+  |  |   +---------------+  |  |
 377     |   |  Application  |  |  |   |  Application  |  |  |
 378     |   +---------------+  |  |   +---------------+  |  |
 379     |       ^       |      |  |       ^       |      |  |
 380     |       |       v      |  |       |       v      |  |  Guests
 381     |   +---------------+  |  |   +---------------+  |  |
 382     |   | logical ports |  |  |   | logical ports |  |  |
 383     |   |   0       1   |  |  |   |   0       1   |  |  |
 384     +---+---------------+--+  +---+---------------+--+ _|
 385             ^       :                 ^       :
 386             |       |                 |       |
 387             :       v                 :       v        _
 388     +---+---------------+---------+---------------+--+  |
 389     |   |   0       1   |         |   3       4   |  |  |
 390     |   | logical ports |         | logical ports |  |  |
 391     |   +---------------+         +---------------+  |  |
 392     |       ^       |                 ^       |      |  |  Host
 393     |       |       L-----------------+       v      |  |
 394     |   +--------------+          +--------------+   |  |
 395     |   |   phy ports  | vSwitch  |   phy ports  |   |  |
 396     +---+--------------+----------+--------------+---+ _|
 397             ^       ^                 :       :
 398             |       |                 |       |
 399             :       :                 v       v
 400     +--------------------------------------------------+
 401     |                                                  |
 402     |                traffic generator                 |
 403     |                                                  |
 404     +--------------------------------------------------+
 405
 406 .. 3.2.5.1.4
 407
 408 Physical port → VNF → vSwitch → VNF → physical port
 409 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 410
 411 .. code-block:: console
 412
 413                                                         _
 414     +----------------------+  +----------------------+   |
 415     |   Guest 1            |  |   Guest 2            |   |
 416     |+-------------------+ |  | +-------------------+|   |
 417     ||     Application   | |  | |     Application   ||   |
 418     |+-------------------+ |  | +-------------------+|   |
 419     |       ^       |      |  |       ^       |      |   |  Guests
 420     |       |       v      |  |       |       v      |   |
 421     |+-------------------+ |  | +-------------------+|   |
 422     ||   logical ports   | |  | |   logical ports   ||   |
 423     ||  0              1 | |  | | 0              1  ||   |
 424     ++--------------------++  ++--------------------++  _|
 425         ^              :          ^              :
 426     (PCI passthrough)  |          |     (PCI passthrough)
 427         |              v          :              |      _
 428     +--------++------------+-+------------++---------+   |
 429     |   |    ||        0   | |    1       ||     |   |   |
 430     |   |    ||logical port| |logical port||     |   |   |
 431     |   |    |+------------+ +------------+|     |   |   |
 432     |   |    |     |                 ^     |     |   |   |
 433     |   |    |     L-----------------+     |     |   |   |
 434     |   |    |                             |     |   |   |  Host
 435     |   |    |           vSwitch           |     |   |   |
 436     |   |    +-----------------------------+     |   |   |
 437     |   |                                        |   |   |
 438     |   |                                        v   |   |
 439     | +--------------+              +--------------+ |   |
 440     | | phy port/VF  |              | phy port/VF  | |   |
 441     +-+--------------+--------------+--------------+-+  _|
 442         ^                                        :
 443         |                                        |
 444         :                                        v
 445     +--------------------------------------------------+
 446     |                                                  |
 447     |                traffic generator                 |
 448     |                                                  |
 449     +--------------------------------------------------+
 450
 451 .. 3.2.5.1.5
 452
 453 Physical port → vSwitch → VNF
 454 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 455
 456 .. code-block:: console
 457
 458                                                           _
 459     +---------------------------------------------------+  |
 460     |                                                   |  |
 461     |   +-------------------------------------------+   |  |
 462     |   |                 Application               |   |  |
 463     |   +-------------------------------------------+   |  |
 464     |       ^                                           |  |
 465     |       |                                           |  |  Guest
 466     |       :                                           |  |
 467     |   +---------------+                               |  |
 468     |   | logical port 0|                               |  |
 469     +---+---------------+-------------------------------+ _|
 470             ^
 471             |
 472             :                                            _
 473     +---+---------------+------------------------------+  |
 474     |   | logical port 0|                              |  |
 475     |   +---------------+                              |  |
 476     |       ^                                          |  |
 477     |       |                                          |  |  Host
 478     |       :                                          |  |
 479     |   +--------------+                               |  |
 480     |   |   phy port   |  vSwitch                      |  |
 481     +---+--------------+------------ -------------- ---+ _|
 482                ^
 483                |
 484                :
 485     +--------------------------------------------------+
 486     |                                                  |
 487     |                traffic generator                 |
 488     |                                                  |
 489     +--------------------------------------------------+
 490
 491 .. 3.2.5.1.6
 492
 493 VNF → vSwitch → physical port
 494 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 495
 496 .. code-block:: console
 497
 498                                                           _
 499     +---------------------------------------------------+  |
 500     |                                                   |  |
 501     |   +-------------------------------------------+   |  |
 502     |   |                 Application               |   |  |
 503     |   +-------------------------------------------+   |  |
 504     |                                          :        |  |
 505     |                                          |        |  |  Guest
 506     |                                          v        |  |
 507     |                               +---------------+   |  |
 508     |                               | logical port  |   |  |
 509     +-------------------------------+---------------+---+ _|
 510                                                :
 511                                                |
 512                                                v         _
 513     +------------------------------+---------------+---+  |
 514     |                              | logical port  |   |  |
 515     |                              +---------------+   |  |
 516     |                                          :       |  |
 517     |                                          |       |  |  Host
 518     |                                          v       |  |
 519     |                               +--------------+   |  |
 520     |                     vSwitch   |   phy port   |   |  |
 521     +-------------------------------+--------------+---+ _|
 522                                            :
 523                                            |
 524                                            v
 525     +--------------------------------------------------+
 526     |                                                  |
 527     |                traffic generator                 |
 528     |                                                  |
 529     +--------------------------------------------------+
 530
 531 .. 3.2.5.1.7
 532
 533 VNF → vSwitch → VNF → vSwitch
 534 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 535
 536 .. code-block:: console
 537
 538                                                              _
 539     +-------------------------+  +-------------------------+  |
 540     |   Guest 1               |  |   Guest 2               |  |
 541     |   +-----------------+   |  |   +-----------------+   |  |
 542     |   |   Application   |   |  |   |   Application   |   |  |
 543     |   +-----------------+   |  |   +-----------------+   |  |
 544     |                :        |  |       ^                 |  |
 545     |                |        |  |       |                 |  |  Guest
 546     |                v        |  |       :                 |  |
 547     |     +---------------+   |  |   +---------------+     |  |
 548     |     | logical port 0|   |  |   | logical port 0|     |  |
 549     +-----+---------------+---+  +---+---------------+-----+ _|
 550                     :                    ^
 551                     |                    |
 552                     v                    :                    _
 553     +----+---------------+------------+---------------+-----+  |
 554     |    |     port 0    |            |     port 1    |     |  |
 555     |    +---------------+            +---------------+     |  |
 556     |              :                    ^                   |  |
 557     |              |                    |                   |  |  Host
 558     |              +--------------------+                   |  |
 559     |                                                       |  |
 560     |                     vswitch                           |  |
 561     +-------------------------------------------------------+ _|
 562
 563 .. 3.2.5.1.8
 564
 565 HOST 1(Physical port → virtual switch → VNF → virtual switch → Physical port)
 566 → HOST 2(Physical port → virtual switch → VNF → virtual switch → Physical port)
 567
 568 HOST 1 (PVP) → HOST 2 (PVP)
 569 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 570
 571 .. code-block:: console
 572
 573                                                        _
 574     +----------------------+  +----------------------+  |
 575     |   Guest 1            |  |   Guest 2            |  |
 576     |   +---------------+  |  |   +---------------+  |  |
 577     |   |  Application  |  |  |   |  Application  |  |  |
 578     |   +---------------+  |  |   +---------------+  |  |
 579     |       ^       |      |  |       ^       |      |  |
 580     |       |       v      |  |       |       v      |  |  Guests
 581     |   +---------------+  |  |   +---------------+  |  |
 582     |   | logical ports |  |  |   | logical ports |  |  |
 583     |   |   0       1   |  |  |   |   0       1   |  |  |
 584     +---+---------------+--+  +---+---------------+--+ _|
 585             ^       :                 ^       :
 586             |       |                 |       |
 587             :       v                 :       v        _
 588     +---+---------------+--+  +---+---------------+--+  |
 589     |   |   0       1   |  |  |   |   3       4   |  |  |
 590     |   | logical ports |  |  |   | logical ports |  |  |
 591     |   +---------------+  |  |   +---------------+  |  |
 592     |       ^       |      |  |       ^       |      |  |  Hosts
 593     |       |       v      |  |       |       v      |  |
 594     |   +--------------+   |  |   +--------------+   |  |
 595     |   |   phy ports  |   |  |   |   phy ports  |   |  |
 596     +---+--------------+---+  +---+--------------+---+ _|
 597             ^       :                 :       :
 598             |       +-----------------+       |
 599             :                                 v
 600     +--------------------------------------------------+
 601     |                                                  |
 602     |                traffic generator                 |
 603     |                                                  |
 604     +--------------------------------------------------+
 605
 606
 607
 608 **Note:** For tests where the traffic generator and/or measurement
 609 receiver are implemented on VM and connected to the virtual switch
 610 through vNIC, the issues of shared resources and interactions between
 611 the measurement devices and the device under test must be considered.
 612
 613 **Note:** Some RFC 2889 tests require a full-mesh sending and receiving
 614 pattern involving more than two ports. This possibility is illustrated in the
 615 Physical port → vSwitch → VNF → vSwitch → VNF → vSwitch → physical port
 616 diagram above (with 2 sending and 2 receiving ports, though all ports
 617 could be used bi-directionally).
 618
 619 **Note:** When Deployment Scenarios are used in RFC 2889 address learning
 620 or cache capacity testing, an additional port from the vSwitch must be
 621 connected to the test device. This port is used to listen for flooded
 622 frames.
 623
 624 .. 3.2.5.2
 625
 626 General Methodology:
 627 --------------------------
 628 To establish the baseline performance of the virtual switch, tests would
 629 initially be run with a simple workload in the VNF (the recommended
 630 simple workload VNF would be `DPDK <http://www.dpdk.org/>`__'s testpmd
 631 application forwarding packets in a VM or vloop\_vnf a simple kernel
 632 module that forwards traffic between two network interfaces inside the
 633 virtualized environment while bypassing the networking stack).
 634 Subsequently, the tests would also be executed with a real Telco
 635 workload running in the VNF, which would exercise the virtual switch in
 636 the context of higher level Telco NFV use cases, and prove that its
 637 underlying characteristics and behaviour can be measured and validated.
 638 Suitable real Telco workload VNFs are yet to be identified.
 639
 640 .. 3.2.5.2.1
 641
 642 Default Test Parameters
 643 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 644
 645 The following list identifies the default parameters for suite of
 646 tests:
 647
 648 -  Reference application: Simple forwarding or Open Source VNF.
 649 -  Frame size (bytes): 64, 128, 256, 512, 1024, 1280, 1518, 2K, 4k OR
 650    Packet size based on use-case (e.g. RTP 64B, 256B) OR Mix of packet sizes as
 651    maintained by the Functest project <https://wiki.opnfv.org/traffic_profile_management>.
 652 -  Reordering check: Tests should confirm that packets within a flow are
 653    not reordered.
 654 -  Duplex: Unidirectional / Bidirectional. Default: Full duplex with
 655    traffic transmitting in both directions, as network traffic generally
 656    does not flow in a single direction. By default the data rate of
 657    transmitted traffic should be the same in both directions, please
 658    note that asymmetric traffic (e.g. downlink-heavy) tests will be
 659    mentioned explicitly for the relevant test cases.
 660 -  Number of Flows: Default for non scalability tests is a single flow.
 661    For scalability tests the goal is to test with maximum supported
 662    flows but where possible will test up to 10 Million flows. Start with
 663    a single flow and scale up. By default flows should be added
 664    sequentially, tests that add flows simultaneously will explicitly
 665    call out their flow addition behaviour. Packets are generated across
 666    the flows uniformly with no burstiness. For multi-core tests should
 667    consider the number of packet flows based on vSwitch/VNF multi-thread
 668    implementation and behavior.
 669
 670 -  Traffic Types: UDP, SCTP, RTP, GTP and UDP traffic.
 671 -  Deployment scenarios are:
 672 -  Physical → virtual switch → physical.
 673 -  Physical → virtual switch → VNF → virtual switch → physical.
 674 -  Physical → virtual switch → VNF → virtual switch → VNF → virtual
 675    switch → physical.
 676 -  Physical → VNF → virtual switch → VNF → physical.
 677 -  Physical → virtual switch → VNF.
 678 -  VNF → virtual switch → Physical.
 679 -  VNF → virtual switch → VNF.
 680
 681 Tests MUST have these parameters unless otherwise stated. **Test cases
 682 with non default parameters will be stated explicitly**.
 683
 684 **Note**: For throughput tests unless stated otherwise, test
 685 configurations should ensure that traffic traverses the installed flows
 686 through the virtual switch, i.e. flows are installed and have an appropriate
 687 time out that doesn't expire before packet transmission starts.
 688
 689 .. 3.2.5.2.2
 690
 691 Flow Classification
 692 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 693
 694 Virtual switches classify packets into flows by processing and matching
 695 particular header fields in the packet/frame and/or the input port where
 696 the packets/frames arrived. The vSwitch then carries out an action on
 697 the group of packets that match the classification parameters. Thus a
 698 flow is considered to be a sequence of packets that have a shared set of
 699 header field values or have arrived on the same port and have the same
 700 action applied to them. Performance results can vary based on the
 701 parameters the vSwitch uses to match for a flow. The recommended flow
 702 classification parameters for L3 vSwitch performance tests are: the
 703 input port, the source IP address, the destination IP address and the
 704 Ethernet protocol type field. It is essential to increase the flow
 705 time-out time on a vSwitch before conducting any performance tests that
 706 do not measure the flow set-up time. Normally the first packet of a
 707 particular flow will install the flow in the vSwitch which adds an
 708 additional latency, subsequent packets of the same flow are not subject
 709 to this latency if the flow is already installed on the vSwitch.
 710
 711 .. 3.2.5.2.3
 712
 713 Test Priority
 714 ~~~~~~~~~~~~~~~~~~~~~
 715
 716 Tests will be assigned a priority in order to determine which tests
 717 should be implemented immediately and which tests implementations
 718 can be deferred.
 719
 720 Priority can be of following types: - Urgent: Must be implemented
 721 immediately. - High: Must be implemented in the next release. - Medium:
 722 May be implemented after the release. - Low: May or may not be
 723 implemented at all.
 724
 725 .. 3.2.5.2.4
 726
 727 SUT Setup
 728 ~~~~~~~~~~~~~~~~~~
 729
 730 The SUT should be configured to its "default" state. The
 731 SUT's configuration or set-up must not change between tests in any way
 732 other than what is required to do the test. All supported protocols must
 733 be configured and enabled for each test set up.
 734
 735 .. 3.2.5.2.5
 736
 737 Port Configuration
 738 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 739
 740 The DUT should be configured with n ports where
 741 n is a multiple of 2. Half of the ports on the DUT should be used as
 742 ingress ports and the other half of the ports on the DUT should be used
 743 as egress ports. Where a DUT has more than 2 ports, the ingress data
 744 streams should be set-up so that they transmit packets to the egress
 745 ports in sequence so that there is an even distribution of traffic
 746 across ports. For example, if a DUT has 4 ports 0(ingress), 1(ingress),
 747 2(egress) and 3(egress), the traffic stream directed at port 0 should
 748 output a packet to port 2 followed by a packet to port 3. The traffic
 749 stream directed at port 1 should also output a packet to port 2 followed
 750 by a packet to port 3.
 751
 752 .. 3.2.5.2.6
 753
 754 Frame Formats
 755 ~~~~~~~~~~~~~~~~~~~~~
 756
 757 **Frame formats Layer 2 (data link layer) protocols**
 758
 759 -  Ethernet II
 760
 761 .. code-block:: console
 762
 763      +---------------------------+-----------+
 764      | Ethernet Header | Payload | Check Sum |
 765      +-----------------+---------+-----------+
 766      |_________________|_________|___________|
 767            14 Bytes     46 - 1500   4 Bytes
 768                           Bytes
 769
 770
 771 **Layer 3 (network layer) protocols**
 772
 773 -  IPv4
 774
 775 .. code-block:: console
 776
 777      +-----------------+-----------+---------+-----------+
 778      | Ethernet Header | IP Header | Payload | Checksum  |
 779      +-----------------+-----------+---------+-----------+
 780      |_________________|___________|_________|___________|
 781            14 Bytes       20 bytes  26 - 1480   4 Bytes
 782                                       Bytes
 783
 784 -  IPv6
 785
 786 .. code-block:: console
 787
 788      +-----------------+-----------+---------+-----------+
 789      | Ethernet Header | IP Header | Payload | Checksum  |
 790      +-----------------+-----------+---------+-----------+
 791      |_________________|___________|_________|___________|
 792            14 Bytes       40 bytes  26 - 1460   4 Bytes
 793                                       Bytes
 794
 795 **Layer 4 (transport layer) protocols**
 796
 797   - TCP
 798   - UDP
 799   - SCTP
 800
 801 .. code-block:: console
 802
 803      +-----------------+-----------+-----------------+---------+-----------+
 804      | Ethernet Header | IP Header | Layer 4 Header  | Payload | Checksum  |
 805      +-----------------+-----------+-----------------+---------+-----------+
 806      |_________________|___________|_________________|_________|___________|
 807            14 Bytes      40 bytes      20 Bytes       6 - 1460   4 Bytes
 808                                                        Bytes
 809
 810
 811 **Layer 5 (application layer) protocols**
 812
 813   - RTP
 814   - GTP
 815
 816 .. code-block:: console
 817
 818      +-----------------+-----------+-----------------+---------+-----------+
 819      | Ethernet Header | IP Header | Layer 4 Header  | Payload | Checksum  |
 820      +-----------------+-----------+-----------------+---------+-----------+
 821      |_________________|___________|_________________|_________|___________|
 822            14 Bytes      20 bytes     20 Bytes        >= 6 Bytes   4 Bytes
 823
 824 .. 3.2.5.2.7
 825
 826 Packet Throughput
 827 ~~~~~~~~~~~~~~~~~~~~~~~~~
 828 There is a difference between an Ethernet frame,
 829 an IP packet, and a UDP datagram. In the seven-layer OSI model of
 830 computer networking, packet refers to a data unit at layer 3 (network
 831 layer). The correct term for a data unit at layer 2 (data link layer) is
 832 a frame, and at layer 4 (transport layer) is a segment or datagram.
 833
 834 Important concepts related to 10GbE performance are frame rate and
 835 throughput. The MAC bit rate of 10GbE, defined in the IEEE standard 802
 836 .3ae, is 10 billion bits per second. Frame rate is based on the bit rate
 837 and frame format definitions. Throughput, defined in IETF RFC 1242, is
 838 the highest rate at which the system under test can forward the offered
 839 load, without loss.
 840
 841 The frame rate for 10GbE is determined by a formula that divides the 10
 842 billion bits per second by the preamble + frame length + inter-frame
 843 gap.
 844
 845 The maximum frame rate is calculated using the minimum values of the
 846 following parameters, as described in the IEEE 802 .3ae standard:
 847
 848 -  Preamble: 8 bytes \* 8 = 64 bits
 849 -  Frame Length: 64 bytes (minimum) \* 8 = 512 bits
 850 -  Inter-frame Gap: 12 bytes (minimum) \* 8 = 96 bits
 851
 852 Therefore, Maximum Frame Rate (64B Frames)
 853 = MAC Transmit Bit Rate / (Preamble + Frame Length + Inter-frame Gap)
 854 = 10,000,000,000 / (64 + 512 + 96)
 855 = 10,000,000,000 / 672
 856 = 14,880,952.38 frame per second (fps)
 857
 858 .. 3.2.5.3
 859
 860 RFCs for testing virtual switch performance
 861 --------------------------------------------------
 862
 863 The starting point for defining the suite of tests for benchmarking the
 864 performance of a virtual switch is to take existing RFCs and standards
 865 that were designed to test their physical counterparts and adapting them
 866 for testing virtual switches. The rationale behind this is to establish
 867 a fair comparison between the performance of virtual and physical
 868 switches. This section outlines the RFCs that are used by this
 869 specification.
 870
 871 .. 3.2.5.3.1
 872
 873 RFC 1242 Benchmarking Terminology for Network Interconnection
 874 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 875 Devices RFC 1242 defines the terminology that is used in describing
 876 performance benchmarking tests and their results. Definitions and
 877 discussions covered include: Back-to-back, bridge, bridge/router,
 878 constant load, data link frame size, frame loss rate, inter frame gap,
 879 latency, and many more.
 880
 881 .. 3.2.5.3.2
 882
 883 RFC 2544 Benchmarking Methodology for Network Interconnect Devices
 884 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 885 RFC 2544 outlines a benchmarking methodology for network Interconnect
 886 Devices. The methodology results in performance metrics such as latency,
 887 frame loss percentage, and maximum data throughput.
 888
 889 In this document network “throughput” (measured in millions of frames
 890 per second) is based on RFC 2544, unless otherwise noted. Frame size
 891 refers to Ethernet frames ranging from smallest frames of 64 bytes to
 892 largest frames of 9K bytes.
 893
 894 Types of tests are:
 895
 896 1. Throughput test defines the maximum number of frames per second
 897    that can be transmitted without any error, or 0% loss ratio.
 898    In some Throughput tests (and those tests with long duration),
 899    evaluation of an additional frame loss ratio is suggested. The
 900    current ratio (10^-7 %) is based on understanding the typical
 901    user-to-user packet loss ratio needed for good application
 902    performance and recognizing that a single transfer through a
 903    vswitch must contribute a tiny fraction of user-to-user loss.
 904    Further, the ratio 10^-7 % also recognizes practical limitations
 905    when measuring loss ratio.
 906
 907 2. Latency test measures the time required for a frame to travel from
 908    the originating device through the network to the destination device.
 909    Please note that RFC2544 Latency measurement will be superseded with
 910    a measurement of average latency over all successfully transferred
 911    packets or frames.
 912
 913 3. Frame loss test measures the network’s
 914    response in overload conditions - a critical indicator of the
 915    network’s ability to support real-time applications in which a
 916    large amount of frame loss will rapidly degrade service quality.
 917
 918 4. Burst test assesses the buffering capability of a virtual switch. It
 919    measures the maximum number of frames received at full line rate
 920    before a frame is lost. In carrier Ethernet networks, this
 921    measurement validates the excess information rate (EIR) as defined in
 922    many SLAs.
 923
 924 5. System recovery to characterize speed of recovery from an overload
 925    condition.
 926
 927 6. Reset to characterize speed of recovery from device or software
 928    reset. This type of test has been updated by `RFC6201
 929    <https://www.rfc-editor.org/rfc/rfc6201.txt>`__ as such,
 930    the methodology defined by this specification will be that of RFC 6201.
 931
 932 Although not included in the defined RFC 2544 standard, another crucial
 933 measurement in Ethernet networking is packet delay variation. The
 934 definition set out by this specification comes from
 935 `RFC5481 <https://www.rfc-editor.org/rfc/rfc5481.txt>`__.
 936
 937 .. 3.2.5.3.3
 938
 939 RFC 2285 Benchmarking Terminology for LAN Switching Devices
 940 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 941 RFC 2285 defines the terminology that is used to describe the
 942 terminology for benchmarking a LAN switching device. It extends RFC
 943 1242 and defines: DUTs, SUTs, Traffic orientation and distribution,
 944 bursts, loads, forwarding rates, etc.
 945
 946 .. 3.2.5.3.4
 947
 948 RFC 2889 Benchmarking Methodology for LAN Switching
 949 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 950 RFC 2889 outlines a benchmarking methodology for LAN switching, it
 951 extends RFC 2544. The outlined methodology gathers performance
 952 metrics for forwarding, congestion control, latency, address handling
 953 and finally filtering.
 954
 955 .. 3.2.5.3.5
 956
 957 RFC 3918 Methodology for IP Multicast Benchmarking
 958 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 959 RFC 3918 outlines a methodology for IP Multicast benchmarking.
 960
 961 .. 3.2.5.3.6
 962
 963 RFC 4737 Packet Reordering Metrics
 964 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 965 RFC 4737 describes metrics for identifying and counting re-ordered
 966 packets within a stream, and metrics to measure the extent each
 967 packet has been re-ordered.
 968
 969 .. 3.2.5.3.7
 970
 971 RFC 5481 Packet Delay Variation Applicability Statement
 972 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 973 RFC 5481 defined two common, but different forms of delay variation
 974 metrics, and compares the metrics over a range of networking
 975 circumstances and tasks. The most suitable form for vSwitch
 976 benchmarking is the "PDV" form.
 977
 978 .. 3.2.5.3.8
 979
 980 RFC 6201 Device Reset Characterization
 981 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 982 RFC 6201 extends the methodology for characterizing the speed of
 983 recovery of the DUT from device or software reset described in RFC
 984 2544.
 985
 986 .. 3.2.6:
 987
 988 .. _PassFailCriteria:
 989
 990 Item pass/fail criteria
 991 =========================
 992
 993 vswitchperf does not specify Pass/Fail criteria for the tests in terms of a
 994 threshold, as benchmarks do not (and should not do this). The results/metrics
 995 for a test are simply reported. If it had to be defined, a test is considered
 996 to have passed if it succesfully completed and a relavent metric was
 997 recorded/reported for the SUT.
 998
 999 .. 3.2.7:
1000
1001 .. _SuspensionResumptionReqs:
1002
1003 Suspension criteria and resumption requirements
1004 ================================================
1005 In the case of a throughput test, a test should be suspended if a virtual
1006 switch is failing to forward any traffic. A test should be restarted from a
1007 clean state if the intention is to carry out the test again.
1008
1009 .. 3.2.8:
1010
1011 .. _TestDelierables:
1012
1013 Test deliverables
1014 ==================
1015 Each test should produce a test report that details SUT information as well as
1016 the test results. There are a number of parameters related to the system, DUT
1017 and tests that can affect the repeatability of a test results and should be
1018 recorded. In order to minimise the variation in the results of a test,
1019 it is recommended that the test report includes the following information:
1020
1021 -  Hardware details including:
1022
1023    -  Platform details.
1024    -  Processor details.
1025    -  Memory information (see below)
1026    -  Number of enabled cores.
1027    -  Number of cores used for the test.
1028    -  Number of physical NICs, as well as their details (manufacturer,
1029       versions, type and the PCI slot they are plugged into).
1030    -  NIC interrupt configuration.
1031    -  BIOS version, release date and any configurations that were
1032       modified.
1033
1034 -  Software details including:
1035
1036    -  OS version (for host and VNF)
1037    -  Kernel version (for host and VNF)
1038    -  GRUB boot parameters (for host and VNF).
1039    -  Hypervisor details (Type and version).
1040    -  Selected vSwitch, version number or commit id used.
1041    -  vSwitch launch command line if it has been parameterised.
1042    -  Memory allocation to the vSwitch – which NUMA node it is using,
1043       and how many memory channels.
1044    -  Where the vswitch is built from source: compiler details including
1045       versions and the flags that were used to compile the vSwitch.
1046    -  DPDK or any other SW dependency version number or commit id used.
1047    -  Memory allocation to a VM - if it's from Hugpages/elsewhere.
1048    -  VM storage type: snapshot/independent persistent/independent
1049       non-persistent.
1050    -  Number of VMs.
1051    -  Number of Virtual NICs (vNICs), versions, type and driver.
1052    -  Number of virtual CPUs and their core affinity on the host.
1053    -  Number vNIC interrupt configuration.
1054    -  Thread affinitization for the applications (including the vSwitch
1055       itself) on the host.
1056    -  Details of Resource isolation, such as CPUs designated for
1057       Host/Kernel (isolcpu) and CPUs designated for specific processes
1058       (taskset).
1059
1060 -  Memory Details
1061
1062    -  Total memory
1063    -  Type of memory
1064    -  Used memory
1065    -  Active memory
1066    -  Inactive memory
1067    -  Free memory
1068    -  Buffer memory
1069    -  Swap cache
1070    -  Total swap
1071    -  Used swap
1072    -  Free swap
1073
1074 -  Test duration.
1075 -  Number of flows.
1076 -  Traffic Information:
1077
1078    -  Traffic type - UDP, TCP, IMIX / Other.
1079    -  Packet Sizes.
1080
1081 -  Deployment Scenario.
1082
1083 **Note**: Tests that require additional parameters to be recorded will
1084 explicitly specify this.
1085
1086
1087 .. 3.3:
1088
1089 .. _TestManagement:
1090
1091 Test management
1092 =================
1093 This section will detail the test activities that will be conducted by vsperf
1094 as well as the infrastructure that will be used to complete the tests in OPNFV.
1095
1096 .. 3.3.1:
1097
1098 Planned activities and tasks; test progression
1099 =================================================
1100 A key consideration when conducting any sort of benchmark is trying to
1101 ensure the consistency and repeatability of test results between runs.
1102 When benchmarking the performance of a virtual switch there are many
1103 factors that can affect the consistency of results. This section
1104 describes these factors and the measures that can be taken to limit
1105 their effects. In addition, this section will outline some system tests
1106 to validate the platform and the VNF before conducting any vSwitch
1107 benchmarking tests.
1108
1109 **System Isolation:**
1110
1111 When conducting a benchmarking test on any SUT, it is essential to limit
1112 (and if reasonable, eliminate) any noise that may interfere with the
1113 accuracy of the metrics collected by the test. This noise may be
1114 introduced by other hardware or software (OS, other applications), and
1115 can result in significantly varying performance metrics being collected
1116 between consecutive runs of the same test. In the case of characterizing
1117 the performance of a virtual switch, there are a number of configuration
1118 parameters that can help increase the repeatability and stability of
1119 test results, including:
1120
1121 -  OS/GRUB configuration:
1122
1123    -  maxcpus = n where n >= 0; limits the kernel to using 'n'
1124       processors. Only use exactly what you need.
1125    -  isolcpus: Isolate CPUs from the general scheduler. Isolate all
1126       CPUs bar one which will be used by the OS.
1127    -  use taskset to affinitize the forwarding application and the VNFs
1128       onto isolated cores. VNFs and the vSwitch should be allocated
1129       their own cores, i.e. must not share the same cores. vCPUs for the
1130       VNF should be affinitized to individual cores also.
1131    -  Limit the amount of background applications that are running and
1132       set OS to boot to runlevel 3. Make sure to kill any unnecessary
1133       system processes/daemons.
1134    -  Only enable hardware that you need to use for your test – to
1135       ensure there are no other interrupts on the system.
1136    -  Configure NIC interrupts to only use the cores that are not
1137       allocated to any other process (VNF/vSwitch).
1138
1139 -  NUMA configuration: Any unused sockets in a multi-socket system
1140    should be disabled.
1141 -  CPU pinning: The vSwitch and the VNF should each be affinitized to
1142    separate logical cores using a combination of maxcpus, isolcpus and
1143    taskset.
1144 -  BIOS configuration: BIOS should be configured for performance where
1145    an explicit option exists, sleep states should be disabled, any
1146    virtualization optimization technologies should be enabled, and
1147    hyperthreading should also be enabled, turbo boost and overclocking
1148    should be disabled.
1149
1150 **System Validation:**
1151
1152 System validation is broken down into two sub-categories: Platform
1153 validation and VNF validation. The validation test itself involves
1154 verifying the forwarding capability and stability for the sub-system
1155 under test. The rationale behind system validation is two fold. Firstly
1156 to give a tester confidence in the stability of the platform or VNF that
1157 is being tested; and secondly to provide base performance comparison
1158 points to understand the overhead introduced by the virtual switch.
1159
1160 * Benchmark platform forwarding capability: This is an OPTIONAL test
1161   used to verify the platform and measure the base performance (maximum
1162   forwarding rate in fps and latency) that can be achieved by the
1163   platform without a vSwitch or a VNF. The following diagram outlines
1164   the set-up for benchmarking Platform forwarding capability:
1165
1166   .. code-block:: console
1167
1168                                                             __
1169        +--------------------------------------------------+   |
1170        |   +------------------------------------------+   |   |
1171        |   |                                          |   |   |
1172        |   |          l2fw or DPDK L2FWD app          |   |  Host
1173        |   |                                          |   |   |
1174        |   +------------------------------------------+   |   |
1175        |   |                 NIC                      |   |   |
1176        +---+------------------------------------------+---+ __|
1177                   ^                           :
1178                   |                           |
1179                   :                           v
1180        +--------------------------------------------------+
1181        |                                                  |
1182        |                traffic generator                 |
1183        |                                                  |
1184        +--------------------------------------------------+
1185
1186 * Benchmark VNF forwarding capability: This test is used to verify
1187   the VNF and measure the base performance (maximum forwarding rate in
1188   fps and latency) that can be achieved by the VNF without a vSwitch.
1189   The performance metrics collected by this test will serve as a key
1190   comparison point for NIC passthrough technologies and vSwitches. VNF
1191   in this context refers to the hypervisor and the VM. The following
1192   diagram outlines the set-up for benchmarking VNF forwarding
1193   capability:
1194
1195   .. code-block:: console
1196
1197                                                             __
1198        +--------------------------------------------------+   |
1199        |   +------------------------------------------+   |   |
1200        |   |                                          |   |   |
1201        |   |                 VNF                      |   |   |
1202        |   |                                          |   |   |
1203        |   +------------------------------------------+   |   |
1204        |   |          Passthrough/SR-IOV              |   |  Host
1205        |   +------------------------------------------+   |   |
1206        |   |                 NIC                      |   |   |
1207        +---+------------------------------------------+---+ __|
1208                   ^                           :
1209                   |                           |
1210                   :                           v
1211        +--------------------------------------------------+
1212        |                                                  |
1213        |                traffic generator                 |
1214        |                                                  |
1215        +--------------------------------------------------+
1216
1217
1218 **Methodology to benchmark Platform/VNF forwarding capability**
1219
1220
1221 The recommended methodology for the platform/VNF validation and
1222 benchmark is: - Run `RFC2889 <https://www.rfc-editor.org/rfc/rfc2289.txt>`__
1223 Maximum Forwarding Rate test, this test will produce maximum
1224 forwarding rate and latency results that will serve as the
1225 expected values. These expected values can be used in
1226 subsequent steps or compared with in subsequent validation tests. -
1227 Transmit bidirectional traffic at line rate/max forwarding rate
1228 (whichever is higher) for at least 72 hours, measure throughput (fps)
1229 and latency. - Note: Traffic should be bidirectional. - Establish a
1230 baseline forwarding rate for what the platform can achieve. - Additional
1231 validation: After the test has completed for 72 hours run bidirectional
1232 traffic at the maximum forwarding rate once more to see if the system is
1233 still functional and measure throughput (fps) and latency. Compare the
1234 measure the new obtained values with the expected values.
1235
1236 **NOTE 1**: How the Platform is configured for its forwarding capability
1237 test (BIOS settings, GRUB configuration, runlevel...) is how the
1238 platform should be configured for every test after this
1239
1240 **NOTE 2**: How the VNF is configured for its forwarding capability test
1241 (# of vCPUs, vNICs, Memory, affinitization…) is how it should be
1242 configured for every test that uses a VNF after this.
1243
1244 **Methodology to benchmark the VNF to vSwitch to VNF deployment scenario**
1245
1246 vsperf has identified the following concerns when benchmarking the VNF to
1247 vSwitch to VNF deployment scenario:
1248
1249 * The accuracy of the timing synchronization between VNFs/VMs.
1250 * The clock accuracy of a VNF/VM if they were to be used as traffic generators.
1251 * VNF traffic generator/receiver may be using resources of the system under
1252   test, causing at least three forms of workload to increase as the traffic
1253   load increases (generation, switching, receiving).
1254
1255 The recommendation from vsperf is that tests for this sceanario must
1256 include an external HW traffic generator to act as the tester/traffic transmitter
1257 and receiver. The perscribed methodology to benchmark this deployment scanrio with
1258 an external tester involves the following three steps:
1259
1260 #. Determine the forwarding capability and latency through the virtual interface
1261 connected to the VNF/VM.
1262
1263 .. Figure:: vm2vm_virtual_interface_benchmark.png
1264
1265    Virtual interfaces performance benchmark
1266
1267 #. Determine the forwarding capability and latency through the VNF/hypervisor.
1268
1269 .. Figure:: vm2vm_hypervisor_benchmark.png
1270
1271    Hypervisor performance benchmark
1272
1273 #. Determine the forwarding capability and latency for the VNF to vSwitch to VNF
1274    taking the information from the previous two steps into account.
1275
1276 .. Figure:: vm2vm_benchmark.png
1277
1278    VNF to vSwitch to VNF performance benchmark
1279
1280 vsperf also identified an alternative configuration for the final step:
1281
1282 .. Figure:: vm2vm_alternative_benchmark.png
1283
1284    VNF to vSwitch to VNF alternative performance benchmark
1285
1286 .. 3.3.2:
1287
1288 Environment/infrastructure
1289 ============================
1290 Intel is providing a hosted test-bed with nine bare-metal environments
1291 allocated to different OPNFV projects. Currently a number of servers in
1292 `Intel POD 3 <https://wiki.opnfv.org/display/pharos/Intel+Pod3>`__ are
1293 allocated to vsperf:
1294
1295   * pod3-wcp-node3 and pod3-wcp-node4 which are used for CI jobs.
1296   * pod3-node6 which is used as a vsperf sandbox environment.
1297
1298 vsperf CI
1299 ---------
1300 vsperf CI jobs are broken down into:
1301
1302   * Daily job:
1303
1304     * Runs everyday takes about 10 hours to complete.
1305     * TESTCASES_DAILY='phy2phy_tput back2back phy2phy_tput_mod_vlan
1306       phy2phy_scalability pvp_tput pvp_back2back pvvp_tput pvvp_back2back'.
1307     * TESTPARAM_DAILY='--test-params pkt_sizes=64,128,512,1024,1518'.
1308
1309   * Merge job:
1310
1311     * Runs whenever patches are merged to master.
1312     * Runs a basic Sanity test.
1313
1314   * Verify job:
1315
1316     * Runs every time a patch is pushed to gerrit.
1317     * Builds documentation.
1318
1319 Scripts:
1320 --------
1321 There are 2 scripts that are part of VSPERFs CI:
1322
1323   * build-vsperf.sh: Lives in the VSPERF repository in the ci/ directory and is
1324     used to run vsperf with the appropriate cli parameters.
1325   * vswitchperf.yml: YAML description of our jenkins job. lives in the RELENG
1326     repository.
1327
1328 More info on vsperf CI can be found here:
1329 https://wiki.opnfv.org/display/vsperf/VSPERF+CI
1330
1331 .. 3.3.3:
1332
1333 Responsibilities and authority
1334 ===============================
1335 The group responsible for managing, designing, preparing and executing the
1336 tests listed in the LTD are the vsperf committers and contributors. The vsperf
1337 committers and contributors should work with the relavent OPNFV projects to
1338 ensure that the infrastructure is in place for testing vswitches, and that the
1339 results are published to common end point (a results database).
1340