docs/design/vswitchperf_design.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 ======================
   6 VSPERF Design Document
   7 ======================
   8
   9 Intended Audience
  10 =================
  11
  12 This document is intended to aid those who want to modify the vsperf code. Or
  13 to extend it - for example to add support for new traffic generators,
  14 deployment scenarios and so on.
  15
  16 Usage
  17 =====
  18
  19 Example Connectivity to DUT
  20 ---------------------------
  21
  22 Establish connectivity to the VSPERF DUT Linux host, such as the DUT in Pod 3,
  23 by following the steps in `Testbed POD3
  24 <https://wiki.opnfv.org/get_started/pod_3_-_characterize_vswitch_performance>`__
  25
  26 The steps cover booking the DUT and establishing the VSPERF environment.
  27
  28 Example Command Lines
  29 ---------------------
  30
  31 List all the cli options:
  32
  33 .. code-block:: console
  34
  35    $ ./vsperf -h
  36
  37 Run all tests that have ``tput`` in their name - ``phy2phy_tput``, ``pvp_tput`` etc.:
  38
  39 .. code-block:: console
  40
  41    $ ./vsperf --tests 'tput'
  42
  43 As above but override default configuration with settings in '10_custom.conf'.
  44 This is useful as modifying configuration directly in the configuration files
  45 in ``conf/NN_*.py`` shows up as changes under git source control:
  46
  47 .. code-block:: console
  48
  49    $ ./vsperf --conf-file=<path_to_custom_conf>/10_custom.conf --tests 'tput'
  50
  51 Override specific test parameters. Useful for shortening the duration of tests
  52 for development purposes:
  53
  54 .. code-block:: console
  55
  56    $ ./vsperf --test-params 'duration=10;rfc2544_tests=1;pkt_sizes=64' --tests 'pvp_tput'
  57
  58 Typical Test Sequence
  59 =====================
  60
  61 This is a typical flow of control for a test.
  62
  63 .. image:: vsperf.png
  64
  65
  66 Configuration
  67 =============
  68
  69 The conf package contains the configuration files (``*.conf``) for all system
  70 components, it also provides a ``settings`` object that exposes all of these
  71 settings.
  72
  73 Settings are not passed from component to component. Rather they are available
  74 globally to all components once they import the conf package.
  75
  76 .. code-block:: python
  77
  78    from conf import settings
  79    ...
  80    log_file = settings.getValue('LOG_FILE_DEFAULT')
  81
  82 Settings files (``*.conf``) are valid python code so can be set to complex
  83 types such as lists and dictionaries as well as scalar types:
  84
  85 .. code-block:: python
  86
  87    first_packet_size = settings.getValue('PACKET_SIZE_LIST')[0]
  88
  89 Configuration Procedure and Precedence
  90 --------------------------------------
  91
  92 Configuration files follow a strict naming convention that allows them to be
  93 processed in a specific order. All the .conf files are named ``NN_name.conf``,
  94 where NN is a decimal number. The files are processed in order from 00_name.conf
  95 to 99_name.conf so that if the name setting is given in both a lower and higher
  96 numbered conf file then the higher numbered file is the effective setting as it
  97 is processed after the setting in the lower numbered file.
  98
  99 The values in the file specified by ``--conf-file`` takes precedence over all
 100 the other configuration files and does not have to follow the naming
 101 convention.
 102
 103 Configuration of PATHS dictionary
 104 ---------------------------------
 105
 106 VSPERF uses external tools like Open vSwitch and Qemu for execution of testcases. These
 107 tools may be downloaded and built automatically by `VSPERF installation scripts`_
 108 or installed manually by user from binary packages. It is also possible to use a combination
 109 of both approaches, but it is essential to correctly set paths to all required tools.
 110 These paths are stored within a PATHS dictionary, which is evaluated before execution
 111 of each testcase, in order to setup testcase specific environment. Values selected for testcase
 112 execution are internally stored inside TOOLS dictionary, which is used by VSPERF to execute
 113 external tools, load kernel modules, etc.
 114
 115 The default configuration of PATHS dictionary is spread among three different configuration files
 116 to follow logical grouping of configuration options. Basic description of PATHS dictionary
 117 is placed inside ``conf/00_common.conf``. The configuration specific to DPDK and vswitches
 118 is located at ``conf/02_vswitch.conf``. The last part related to the Qemu is defined inside
 119 ``conf/04_vnf.conf``. Default configuration values can be used in case, that all required
 120 tools were downloaded and built automatically by vsperf itself. In case, that some of
 121 tools were installed manually from binary packages, then it will be necessary to modify
 122 the content of PATHS dictionary accordingly.
 123
 124 Dictionary has a specific section of configuration options for every tool type, it means:
 125
 126     * ``PATHS['vswitch']`` - contains a separete dictionary for each of vswitches supported by VSPEF
 127
 128       Example:
 129
 130       .. code-block:: python
 131
 132          PATHS['vswitch'] = {
 133             'OvsDpdkVhost': { ... },
 134             'OvsVanilla' : { ... },
 135             ...
 136          }
 137
 138     * ``PATHS['dpdk']`` - contains paths to the dpdk sources, kernel modules and tools (e.g. testpmd)
 139
 140       Example:
 141
 142       .. code-block:: python
 143
 144          PATHS['dpdk'] = {
 145             'type' : 'src',
 146             'src': {
 147                 'path': os.path.join(ROOT_DIR, 'src/dpdk/dpdk/'),
 148                 'modules' : ['uio', os.path.join(RTE_TARGET, 'kmod/igb_uio.ko')],
 149                 'bind-tool': 'tools/dpdk*bind.py',
 150                 'testpmd': os.path.join(RTE_TARGET, 'app', 'testpmd'),
 151             },
 152             ...
 153          }
 154
 155     * ``PATHS['qemu']`` - contains paths to the qemu sources and executable file
 156
 157       Example:
 158
 159       .. code-block:: python
 160
 161          PATHS['qemu'] = {
 162              'type' : 'bin',
 163              'bin': {
 164                  'qemu-system': 'qemu-system-x86_64'
 165              },
 166              ...
 167          }
 168
 169 Every section specific to the particular vswitch, dpdk or qemu may contain following types
 170 of configuration options:
 171
 172     * option ``type`` - is a string, which defines the type of configured paths ('src' or 'bin')
 173       to be selected for a given section:
 174
 175         * value ``src`` means, that VSPERF will use vswitch, DPDK or QEMU built from sources
 176           e.g. by execution of ``systems/build_base_machine.sh`` script during VSPERF
 177           installation
 178
 179         * value ``bin`` means, that VSPERF will use vswitch, DPDK or QEMU binaries installed
 180           directly in the operating system, e.g. via OS specific packaging system
 181
 182     * option ``path`` - is a string with a valid system path; Its content is checked for
 183       existence, prefixed with section name and stored into TOOLS for later use
 184       e.g. ``TOOLS['dpdk_src']`` or ``TOOLS['vswitch_src']``
 185
 186     * option ``modules`` - is list of strings with names of kernel modules; Every module name
 187       from given list is checked for a '.ko' suffix. In case that it matches and if it is not
 188       an absolute path to the module, then module name is prefixed with value of ``path``
 189       option defined for the same section
 190
 191       Example:
 192
 193       .. code-block:: python
 194
 195          """
 196          snippet of PATHS definition from the configuration file:
 197          """
 198          PATHS['vswitch'] = {
 199              'OvsVanilla' = {
 200                  'type' : 'src',
 201                  'src': {
 202                      'path': '/tmp/vsperf/src_vanilla/ovs/ovs/',
 203                      'modules' : ['datapath/linux/openvswitch.ko'],
 204                      ...
 205                  },
 206                  ...
 207              }
 208              ...
 209          }
 210
 211          """
 212          Final content of TOOLS dictionary used during runtime:
 213          """
 214          TOOLS['vswitch_modules'] = ['/tmp/vsperf/src_vanilla/ovs/ovs/datapath/linux/openvswitch.ko']
 215
 216     * all other options are strings with names and paths to specific tools; If a given string
 217       contains a relative path and option ``path`` is defined for a given section, then string
 218       content will be prefixed with content of the ``path``. Otherwise the name of the tool will be
 219       searched within standard system directories. In case that filename contains OS specific
 220       wildcards, then they will be expanded to the real path. At the end of the processing, every
 221       absolute path will be checked for its existence. In case that temporary path (i.e. path with
 222       a ``_tmp`` suffix) does not exist, then log will be written and vsperf will continue. If any
 223       other path will not exist, then vsperf execution will be terminated with a runtime error.
 224
 225       Example:
 226
 227       .. code-block:: python
 228
 229          """
 230          snippet of PATHS definition from the configuration file:
 231          """
 232          PATHS['vswitch'] = {
 233              'OvsDpdkVhost': {
 234                  'type' : 'src',
 235                  'src': {
 236                      'path': '/tmp/vsperf/src_vanilla/ovs/ovs/',
 237                      'ovs-vswitchd': 'vswitchd/ovs-vswitchd',
 238                      'ovsdb-server': 'ovsdb/ovsdb-server',
 239                      ...
 240                  }
 241                  ...
 242              }
 243              ...
 244          }
 245
 246          """
 247          Final content of TOOLS dictionary used during runtime:
 248          """
 249          TOOLS['ovs-vswitchd'] = '/tmp/vsperf/src_vanilla/ovs/ovs/vswitchd/ovs-vswitchd'
 250          TOOLS['ovsdb-server'] = '/tmp/vsperf/src_vanilla/ovs/ovs/ovsdb/ovsdb-server'
 251
 252 Note: In case that ``bin`` type is set for DPDK, then ``TOOLS['dpdk_src']`` will be set to
 253 the value of ``PATHS['dpdk']['src']['path']``. The reason is, that VSPERF uses downloaded
 254 DPDK sources to copy DPDK and testpmd into the GUEST, where testpmd is built. In case,
 255 that DPDK sources are not available, then vsperf will continue with test execution,
 256 but testpmd can't be used as a guest loopback. This is useful in case, that other guest
 257 loopback applications (e.g. buildin or l2fwd) are used.
 258
 259 .. _VSPERF installation scripts: http://artifacts.opnfv.org/vswitchperf/docs/configguide/installation.html#other-requirements
 260
 261 Configuration of GUEST options
 262 ------------------------------
 263
 264 VSPERF is able to setup scenarios involving a number of VMs in series or in parallel.
 265 All configuration options related to a particular VM instance are defined as
 266 lists and prefixed with ``GUEST_`` label. It is essential, that there is enough
 267 items in all ``GUEST_`` options to cover all VM instances involved in the test.
 268 In case there is not enough items, then VSPERF will use the first item of
 269 particular ``GUEST_`` option to expand the list to required length.
 270
 271 Example of option expansion for 4 VMs:
 272
 273     .. code-block:: python
 274
 275        """
 276        Original values:
 277        """
 278        GUEST_SMP = ['2']
 279        GUEST_MEMORY = ['2048', '4096']
 280
 281        """
 282        Values after automatic expansion:
 283        """
 284        GUEST_SMP = ['2', '2', '2', '2']
 285        GUEST_MEMORY = ['2048', '4096', '2048', '2048']
 286
 287
 288 First option can contain macros starting with ``#`` to generate VM specific values.
 289 These macros can be used only for options of ``list`` or ``str`` types with ``GUEST_``
 290 prefix.
 291
 292 Example of macros and their expnasion for 2 VMs:
 293
 294     .. code-block:: python
 295
 296        """
 297        Original values:
 298        """
 299        GUEST_SHARE_DIR = ['/tmp/qemu#VMINDEX_share']
 300        GUEST_BRIDGE_IP = ['#IP(1.1.1.5)/16']
 301
 302        """
 303        Values after automatic expansion:
 304        """
 305        GUEST_SHARE_DIR = ['/tmp/qemu0_share', '/tmp/qemu1_share']
 306        GUEST_BRIDGE_IP = ['1.1.1.5/16', '1.1.1.6/16']
 307
 308 Additional examples are available at ``04_vnf.conf``.
 309
 310 Note: In  case, that macro is detected in the first item of the list, then
 311 all other items are ignored and list content is created automatically.
 312
 313 Multiple macros can be used inside one configuration option definition, but macros
 314 cannot be used inside other macros. The only exception is macro ``#VMINDEX``, which
 315 is expanded first and thus it can be used inside other macros.
 316
 317 Following macros are supported:
 318
 319   * ``#VMINDEX`` - it is replaced by index of VM being executed; This macro
 320     is expanded first, so it can be used inside other macros.
 321
 322     Example:
 323
 324     .. code-block:: python
 325
 326        GUEST_SHARE_DIR = ['/tmp/qemu#VMINDEX_share']
 327
 328   * ``#MAC(mac_address[, step])`` - it will iterate given ``mac_address``
 329     with optional ``step``. In case that step is not defined, then it is set to 1.
 330     It means, that first VM will use the value of ``mac_address``, second VM
 331     value of ``mac_address`` increased by ``step``, etc.
 332
 333     Example:
 334
 335     .. code-block:: python
 336
 337        GUEST_NICS = [[{'mac' : '#MAC(00:00:00:00:00:01,2)'}]]
 338
 339   * ``#IP(ip_address[, step])`` - it will iterate given ``ip_address``
 340     with optional ``step``. In case that step is not defined, then it is set to 1.
 341     It means, that first VM will use the value of ``ip_address``, second VM
 342     value of ``ip_address`` increased by ``step``, etc.
 343
 344     Example:
 345
 346     .. code-block:: python
 347
 348        GUEST_BRIDGE_IP = ['#IP(1.1.1.5)/16']
 349
 350   * ``#EVAL(expression)`` - it will evaluate given ``expression`` as python code;
 351     Only simple expressions should be used. Call of the functions is not supported.
 352
 353     Example:
 354
 355     .. code-block:: python
 356
 357        GUEST_CORE_BINDING = [('#EVAL(6+2*#VMINDEX)', '#EVAL(7+2*#VMINDEX)')]
 358
 359 Other Configuration
 360 -------------------
 361
 362 ``conf.settings`` also loads configuration from the command line and from the environment.
 363
 364 PXP Deployment
 365 ==============
 366
 367 Every testcase uses one of the supported deployment scenarios to setup test environment.
 368 The controller responsible for a given scenario configures flows in the vswitch to route
 369 traffic among physical interfaces connected to the traffic generator and virtual
 370 machines. VSPERF supports several deployments including PXP deployment, which can
 371 setup various scenarios with multiple VMs.
 372
 373 These scenarios are realized by VswitchControllerPXP class, which can configure and
 374 execute given number of VMs in serial or parallel configurations. Every VM can be
 375 configured with just one or an even number of interfaces. In case that VM has more than
 376 2 interfaces, then traffic is properly routed among pairs of interfaces.
 377
 378 Example of traffic routing for VM with 4 NICs in serial configuration:
 379
 380 .. code-block:: console
 381
 382                  +------------------------------------------+
 383                  |  VM with 4 NICs                          |
 384                  |  +---------------+    +---------------+  |
 385                  |  |  Application  |    |  Application  |  |
 386                  |  +---------------+    +---------------+  |
 387                  |      ^       |            ^       |      |
 388                  |      |       v            |       v      |
 389                  |  +---------------+    +---------------+  |
 390                  |  | logical ports |    | logical ports |  |
 391                  |  |   0       1   |    |   2       3   |  |
 392                  +--+---------------+----+---------------+--+
 393                         ^       :            ^       :
 394                         |       |            |       |
 395                         :       v            :       v
 396         +-----------+---------------+----+---------------+----------+
 397         | vSwitch   |   0       1   |    |   2       3   |          |
 398         |           | logical ports |    | logical ports |          |
 399         | previous  +---------------+    +---------------+   next   |
 400         | VM or PHY     ^       |            ^       |     VM or PHY|
 401         |   port   -----+       +------------+       +--->   port   |
 402         +-----------------------------------------------------------+
 403
 404 It is also possible to define different number of interfaces for each VM to better
 405 simulate real scenarios.
 406
 407 Example of traffic routing for 2 VMs in serial configuration, where 1st VM has
 408 4 NICs and 2nd VM 2 NICs:
 409
 410 .. code-block:: console
 411
 412            +------------------------------------------+  +---------------------+
 413            |  1st VM with 4 NICs                      |  |  2nd VM with 2 NICs |
 414            |  +---------------+    +---------------+  |  |  +---------------+  |
 415            |  |  Application  |    |  Application  |  |  |  |  Application  |  |
 416            |  +---------------+    +---------------+  |  |  +---------------+  |
 417            |      ^       |            ^       |      |  |      ^       |      |
 418            |      |       v            |       v      |  |      |       v      |
 419            |  +---------------+    +---------------+  |  |  +---------------+  |
 420            |  | logical ports |    | logical ports |  |  |  | logical ports |  |
 421            |  |   0       1   |    |   2       3   |  |  |  |   0       1   |  |
 422            +--+---------------+----+---------------+--+  +--+---------------+--+
 423                   ^       :            ^       :               ^       :
 424                   |       |            |       |               |       |
 425                   :       v            :       v               :       v
 426   +-----------+---------------+----+---------------+-------+---------------+----------+
 427   | vSwitch   |   0       1   |    |   2       3   |       |   4       5   |          |
 428   |           | logical ports |    | logical ports |       | logical ports |          |
 429   | previous  +---------------+    +---------------+       +---------------+   next   |
 430   | VM or PHY     ^       |            ^       |               ^       |     VM or PHY|
 431   |   port   -----+       +------------+       +---------------+       +---->  port   |
 432   +-----------------------------------------------------------------------------------+
 433
 434 The number of VMs involved in the test and the type of their connection is defined
 435 by deployment name as follows:
 436
 437   * ``pvvp[number]`` - configures scenario with VMs connected in series with
 438     optional ``number`` of VMs. In case that ``number`` is not specified, then
 439     2 VMs will be used.
 440
 441     Example of 2 VMs in a serial configuration:
 442
 443     .. code-block:: console
 444
 445        +----------------------+  +----------------------+
 446        |   1st VM             |  |   2nd VM             |
 447        |   +---------------+  |  |   +---------------+  |
 448        |   |  Application  |  |  |   |  Application  |  |
 449        |   +---------------+  |  |   +---------------+  |
 450        |       ^       |      |  |       ^       |      |
 451        |       |       v      |  |       |       v      |
 452        |   +---------------+  |  |   +---------------+  |
 453        |   | logical ports |  |  |   | logical ports |  |
 454        |   |   0       1   |  |  |   |   0       1   |  |
 455        +---+---------------+--+  +---+---------------+--+
 456                ^       :                 ^       :
 457                |       |                 |       |
 458                :       v                 :       v
 459        +---+---------------+---------+---------------+--+
 460        |   |   0       1   |         |   3       4   |  |
 461        |   | logical ports | vSwitch | logical ports |  |
 462        |   +---------------+         +---------------+  |
 463        |       ^       |                 ^       |      |
 464        |       |       +-----------------+       v      |
 465        |   +----------------------------------------+   |
 466        |   |              physical ports            |   |
 467        |   |      0                         1       |   |
 468        +---+----------------------------------------+---+
 469                   ^                         :
 470                   |                         |
 471                   :                         v
 472        +------------------------------------------------+
 473        |                                                |
 474        |                traffic generator               |
 475        |                                                |
 476        +------------------------------------------------+
 477
 478   * ``pvpv[number]`` - configures scenario with VMs connected in parallel with
 479     optional ``number`` of VMs. In case that ``number`` is not specified, then
 480     2 VMs will be used. Multistream feature is used to route traffic to particular
 481     VMs (or NIC pairs of every VM). It means, that VSPERF will enable multistream
 482     feaure and sets the number of streams to the number of VMs and their NIC
 483     pairs. Traffic will be dispatched based on Stream Type, i.e. by UDP port,
 484     IP address or MAC address.
 485
 486     Example of 2 VMs in a parallel configuration, where traffic is dispatched
 487         based on the UDP port.
 488
 489     .. code-block:: console
 490
 491        +----------------------+  +----------------------+
 492        |   1st VM             |  |   2nd VM             |
 493        |   +---------------+  |  |   +---------------+  |
 494        |   |  Application  |  |  |   |  Application  |  |
 495        |   +---------------+  |  |   +---------------+  |
 496        |       ^       |      |  |       ^       |      |
 497        |       |       v      |  |       |       v      |
 498        |   +---------------+  |  |   +---------------+  |
 499        |   | logical ports |  |  |   | logical ports |  |
 500        |   |   0       1   |  |  |   |   0       1   |  |
 501        +---+---------------+--+  +---+---------------+--+
 502                ^       :                 ^       :
 503                |       |                 |       |
 504                :       v                 :       v
 505        +---+---------------+---------+---------------+--+
 506        |   |   0       1   |         |   3       4   |  |
 507        |   | logical ports | vSwitch | logical ports |  |
 508        |   +---------------+         +---------------+  |
 509        |      ^         |                 ^       :     |
 510        |      |     ......................:       :     |
 511        |  UDP | UDP :   |                         :     |
 512        |  port| port:   +--------------------+    :     |
 513        |   0  |  1  :                        |    :     |
 514        |      |     :                        v    v     |
 515        |   +----------------------------------------+   |
 516        |   |              physical ports            |   |
 517        |   |    0                               1   |   |
 518        +---+----------------------------------------+---+
 519                 ^                               :
 520                 |                               |
 521                 :                               v
 522        +------------------------------------------------+
 523        |                                                |
 524        |                traffic generator               |
 525        |                                                |
 526        +------------------------------------------------+
 527
 528
 529 PXP deployment is backward compatible with PVP deployment, where ``pvp`` is
 530 an alias for ``pvvp1`` and it executes just one VM.
 531
 532 The number of interfaces used by VMs is defined by configuration option
 533 ``GUEST_NICS_NR``. In case that more than one pair of interfaces is defined
 534 for VM, then:
 535
 536     * for ``pvvp`` (serial) scenario every NIC pair is connected in serial
 537       before connection to next VM is created
 538     * for ``pvpv`` (parallel) scenario every NIC pair is directly connected
 539       to the physical ports and unique traffic stream is assigned to it
 540
 541 Examples:
 542
 543     * Deployment ``pvvp10`` will start 10 VMs and connects them in series
 544     * Deployment ``pvpv4`` will start 4 VMs and connects them in parallel
 545     * Deployment ``pvpv1`` and GUEST_NICS_NR = [4] will start 1 VM with
 546       4 interfaces and every NIC pair is directly connected to the
 547       physical ports
 548     * Deployment ``pvvp`` and GUEST_NICS_NR = [2, 4] will start 2 VMs;
 549       1st VM will have 2 interfaces and 2nd VM 4 interfaces. These interfaces
 550       will be connected in serial, i.e. traffic will flow as follows:
 551       PHY1 -> VM1_1 -> VM1_2 -> VM2_1 -> VM2_2 -> VM2_3 -> VM2_4 -> PHY2
 552
 553 Note: In case that only 1 or more than 2 NICs are configured for VM,
 554 then ``testpmd`` should be used as forwarding application inside the VM.
 555 As it is able to forward traffic between multiple VM NIC pairs.
 556
 557 Note: In case of ``linux_bridge``, all NICs are connected to the same
 558 bridge inside the VM.
 559
 560 VM, vSwitch, Traffic Generator Independence
 561 ===========================================
 562
 563 VSPERF supports different vSwithes, Traffic Generators, VNFs
 564 and Forwarding Applications by using standard object-oriented polymorphism:
 565
 566   * Support for vSwitches is implemented by a class inheriting from IVSwitch.
 567   * Support for Traffic Generators is implemented by a class inheriting from
 568     ITrafficGenerator.
 569   * Support for VNF is implemented by a class inheriting from IVNF.
 570   * Support for Forwarding Applications is implemented by a class inheriting
 571     from IPktFwd.
 572
 573 By dealing only with the abstract interfaces the core framework can support
 574 many implementations of different vSwitches, Traffic Generators, VNFs
 575 and Forwarding Applications.
 576
 577 IVSwitch
 578 --------
 579
 580 .. code-block:: python
 581
 582     class IVSwitch:
 583       start(self)
 584       stop(self)
 585       add_switch(switch_name)
 586       del_switch(switch_name)
 587       add_phy_port(switch_name)
 588       add_vport(switch_name)
 589       get_ports(switch_name)
 590       del_port(switch_name, port_name)
 591       add_flow(switch_name, flow)
 592       del_flow(switch_name, flow=None)
 593
 594 ITrafficGenerator
 595 -----------------
 596
 597 .. code-block:: python
 598
 599     class ITrafficGenerator:
 600       connect()
 601       disconnect()
 602
 603       send_burst_traffic(traffic, numpkts, time, framerate)
 604
 605       send_cont_traffic(traffic, time, framerate)
 606       start_cont_traffic(traffic, time, framerate)
 607       stop_cont_traffic(self):
 608
 609       send_rfc2544_throughput(traffic, tests, duration, lossrate)
 610       start_rfc2544_throughput(traffic, tests, duration, lossrate)
 611       wait_rfc2544_throughput(self)
 612
 613       send_rfc2544_back2back(traffic, tests, duration, lossrate)
 614       start_rfc2544_back2back(traffic, , tests, duration, lossrate)
 615       wait_rfc2544_back2back()
 616
 617 Note ``send_xxx()`` blocks whereas ``start_xxx()`` does not and must be followed by a subsequent call to ``wait_xxx()``.
 618
 619 IVnf
 620 ----
 621
 622 .. code-block:: python
 623
 624     class IVnf:
 625       start(memory, cpus,
 626             monitor_path, shared_path_host,
 627             shared_path_guest, guest_prompt)
 628       stop()
 629       execute(command)
 630       wait(guest_prompt)
 631       execute_and_wait (command)
 632
 633 IPktFwd
 634 --------
 635
 636   .. code-block:: python
 637
 638     class IPktFwd:
 639         start()
 640         stop()
 641
 642
 643 Controllers
 644 -----------
 645
 646 Controllers are used in conjunction with abstract interfaces as way
 647 of decoupling the control of vSwtiches, VNFs, TrafficGenerators
 648 and Forwarding Applications from other components.
 649
 650 The controlled classes provide basic primitive operations. The Controllers
 651 sequence and co-ordinate these primitive operation in to useful actions. For
 652 instance the vswitch_controller_p2p can be used to bring any vSwitch (that
 653 implements the primitives defined in IVSwitch) into the configuration required
 654 by the Phy-to-Phy  Deployment Scenario.
 655
 656 In order to support a new vSwitch only a new implementation of IVSwitch needs
 657 be created for the new vSwitch to be capable of fulfilling all the Deployment
 658 Scenarios provided for by existing or future vSwitch Controllers.
 659
 660 Similarly if a new Deployment Scenario is required it only needs to be written
 661 once as a new vSwitch Controller and it will immediately be capable of
 662 controlling all existing and future vSwitches in to that Deployment Scenario.
 663
 664 Similarly the Traffic Controllers can be used to co-ordinate basic operations
 665 provided by implementers of ITrafficGenerator to provide useful tests. Though
 666 traffic generators generally already implement full test cases i.e. they both
 667 generate suitable traffic and analyse returned traffic in order to implement a
 668 test which has typically been predefined in an RFC document. However the
 669 Traffic Controller class allows for the possibility of further enhancement -
 670 such as iterating over tests for various packet sizes or creating new tests.
 671
 672 Traffic Controller's Role
 673 -------------------------
 674
 675 .. image:: traffic_controller.png
 676
 677
 678 Loader & Component Factory
 679 --------------------------
 680
 681 The working of the Loader package (which is responsible for *finding* arbitrary
 682 classes based on configuration data) and the Component Factory which is
 683 responsible for *choosing* the correct class for a particular situation - e.g.
 684 Deployment Scenario can be seen in this diagram.
 685
 686 .. image:: factory_and_loader.png
 687
 688 Routing Tables
 689 ==============
 690
 691 Vsperf uses a standard set of routing tables in order to allow tests to easily
 692 mix and match Deployment Scenarios (PVP, P2P topology), Tuple Matching and
 693 Frame Modification requirements.
 694
 695 .. code-block:: console
 696
 697       +--------------+
 698       |              |
 699       | Table 0      |  table#0 - Match table. Flows designed to force 5 & 10
 700       |              |  tuple matches go here.
 701       |              |
 702       +--------------+
 703              |
 704              |
 705              v
 706       +--------------+  table#1 - Routing table. Flow entries to forward
 707       |              |  packets between ports goes here.
 708       | Table 1      |  The chosen port is communicated to subsequent tables by
 709       |              |  setting the metadata value to the egress port number.
 710       |              |  Generally this table is set-up by by the
 711       +--------------+  vSwitchController.
 712              |
 713              |
 714              v
 715       +--------------+  table#2 - Frame modification table. Frame modification
 716       |              |  flow rules are isolated in this table so that they can
 717       | Table 2      |  be turned on or off without affecting the routing or
 718       |              |  tuple-matching flow rules. This allows the frame
 719       |              |  modification and tuple matching required by the tests
 720       |              |  in the VSWITCH PERFORMANCE FOR TELCO NFV test
 721       +--------------+  specification to be independent of the Deployment
 722              |          Scenario set up by the vSwitchController.
 723              |
 724              v
 725       +--------------+
 726       |              |
 727       | Table 3      |  table#3 - Egress table. Egress packets on the ports
 728       |              |  setup in Table 1.
 729       +--------------+
 730
 731