diff options
| -rwxr-xr-x | conf/01_testcases.conf | 8 | ||||
| -rw-r--r-- | conf/02_vswitch.conf | 8 | ||||
| -rw-r--r-- | conf/04_vnf.conf | 168 | ||||
| -rw-r--r-- | conf/__init__.py | 75 | ||||
| -rw-r--r-- | core/component_factory.py | 25 | ||||
| -rw-r--r-- | core/vnf_controller.py | 56 | ||||
| -rw-r--r-- | core/vswitch_controller_pvp.py | 118 | ||||
| -rw-r--r-- | core/vswitch_controller_pvvp.py | 126 | ||||
| -rw-r--r-- | core/vswitch_controller_pxp.py | 221 | ||||
| -rwxr-xr-x | docs/configguide/installation.rst | 4 | ||||
| -rwxr-xr-x | docs/design/vswitchperf_design.rst | 297 | ||||
| -rwxr-xr-x | docs/msc/vsperf.msc | 4 | ||||
| -rw-r--r-- | docs/requirements/ietf_draft/draft-ietf-bmwg-vswitch-opnfv-00.txt | 1232 | ||||
| -rwxr-xr-x | docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.txt | 1232 | ||||
| -rwxr-xr-x | docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-02.txt | 1232 | ||||
| -rwxr-xr-x | docs/userguide/testusage.rst | 39 | ||||
| -rw-r--r-- | src/dpdk/dpdk.py | 4 | ||||
| -rw-r--r-- | testcases/testcase.py | 75 | ||||
| -rw-r--r-- | vnfs/qemu/qemu.py | 157 | ||||
| -rw-r--r-- | vnfs/qemu/qemu_dpdk_vhost_user.py | 65 | ||||
| -rw-r--r-- | vnfs/qemu/qemu_virtio_net.py | 54 | ||||
| -rw-r--r-- | vnfs/vnf/vnf.py | 2 | ||||
| -rw-r--r-- | vswitches/ovs_vanilla.py | 12 |
23 files changed, 965 insertions, 4249 deletions
diff --git a/conf/01_testcases.conf b/conf/01_testcases.conf index 23a3ae57..b9c59a11 100755 --- a/conf/01_testcases.conf +++ b/conf/01_testcases.conf @@ -171,6 +171,14 @@ PERFORMANCE_TESTS = [ "iLoad": "100", }, { + "Name": "pvpv_cont", + "Traffic Type": "continuous", + "Deployment": "pvpv", + "Description": "Two VMs in parallel with Continuous Stream", + "biDirectional": "True", + "iLoad": "100", + }, + { "Name": "phy2phy_scalability", "Traffic Type": "rfc2544", "Deployment": "p2p", diff --git a/conf/02_vswitch.conf b/conf/02_vswitch.conf index cd2b8d26..abca63bb 100644 --- a/conf/02_vswitch.conf +++ b/conf/02_vswitch.conf @@ -60,13 +60,7 @@ SYS_MODULES = ['uio', 'cuse'] VHOST_DEV_FILE = 'ovs-vhost-net' # location of vhost-user sockets -VHOST_USER_SOCKS = ['/tmp/dpdkvhostuser0', '/tmp/dpdkvhostuser1', - '/tmp/dpdkvhostuser2', '/tmp/dpdkvhostuser3', - '/tmp/dpdkvhostuser4', '/tmp/dpdkvhostuser5', - '/tmp/dpdkvhostuser6', '/tmp/dpdkvhostuser7', - '/tmp/dpdkvhostuser8', '/tmp/dpdkvhostuser9', - '/tmp/dpdkvhostuser10', '/tmp/dpdkvhostuser11', - '/tmp/myport0', '/tmp/helloworld123', '/tmp/abcstuff0'] +VHOST_USER_SOCKS = os.path.join(OVS_VAR_DIR, 'dpdkvhostuser*') # ############################ # vswitch configuration diff --git a/conf/04_vnf.conf b/conf/04_vnf.conf index 05893fb8..2e86b358 100644 --- a/conf/04_vnf.conf +++ b/conf/04_vnf.conf @@ -1,4 +1,4 @@ -# Copyright 2015 Intel Corporation. +# Copyright 2015-2016 Intel Corporation. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. @@ -17,30 +17,68 @@ # ############################ VNF_DIR = 'vnfs/' VNF = 'QemuDpdkVhostUser' +VNF_AFFINITIZATION_ON = True + +# ############################ +# Executables and log files +# ############################ + +QEMU_BIN = os.path.join(QEMU_DIR, 'x86_64-softmmu/qemu-system-x86_64') + +# log file for qemu +LOG_FILE_QEMU = 'qemu.log' + +# log file for all commands executed on guest(s) +# multiple guests will result in log files with the guest number appended +LOG_FILE_GUEST_CMDS = 'guest-cmds.log' # ############################ # Guest configuration # ############################ +# All configuration options related to a particular VM instance are defined as +# lists and prefixed with `GUEST_` label. It is essential, that there is enough +# items in all `GUEST_` options to cover all VM instances involved in the test. +# In case there is not enough items, then VSPERF will use the first item of +# particular `GUEST_` option to expand the list to required length. First option +# can contain macros starting with `#` to generate VM specific values. These +# macros can be used only for options of `list` or `str` types with `GUEST_` +# prefix. +# Following macros are supported: +# +# * #VMINDEX - it is replaced by index of VM being executed; This macro is +# expanded first, so it can be used inside other macros. +# +# * #MAC(mac_address[, step]) - it will iterate given `mac_address` with +# optional `step`. In case that step is not defined, then it is set to 1. +# It means, that first VM will use the value of `mac_address`, second VM +# value of `mac_address` increased by `step`, etc. +# +# * #IP(ip_address[, step]) - it will iterate given `ip_address` with optional +# step. In case that step is not defined, then it is set to 1. +# It means, that first VM will use the value of `ip_address`, second VM +# value of `ip_address` increased by `step`, etc. +# +# * #EVAL(expression) - it will evaluate given `expression` as python code; +# Only simple expressions should be used. Call of the functions is not +# supported. # directory which is shared to QEMU guests. Useful for exchanging files # between host and guest, VNF specific share will be created # For 2 VNFs you may use ['/tmp/qemu0_share', '/tmp/qemu1_share'] -GUEST_SHARE_DIR = ['/tmp/qemu0_share', '/tmp/qemu1_share', \ - '/tmp/qemu2_share', '/tmp/qemu3_share', \ - '/tmp/qemu4_share', '/tmp/qemu5_share'] +GUEST_SHARE_DIR = ['/tmp/qemu0_share'] # location of guest disk image # For 2 VNFs you may use ['guest1.img', 'guest2.img'] -GUEST_IMAGE = ['', '', '', '', '', ''] +GUEST_IMAGE = [''] # guarding timer for VM start up # For 2 VNFs you may use [180, 180] -GUEST_TIMEOUT = [180, 180, 180, 180, 180, 180] +GUEST_TIMEOUT = [180] # Guest images may require different drive types such as ide to mount shared # locations and/or boot correctly. You can modify the types here. -GUEST_BOOT_DRIVE_TYPE = 'scsi' -GUEST_SHARED_DRIVE_TYPE = 'scsi' +GUEST_BOOT_DRIVE_TYPE = ['scsi'] +GUEST_SHARED_DRIVE_TYPE = ['scsi'] # packet forwarding mode supported by testpmd; Please see DPDK documentation # for comprehensive list of modes supported by your version. @@ -57,71 +95,50 @@ GUEST_TESTPMD_FWD_MODE = 'csum' # This configuration option can be overridden by CLI SCALAR option # guest_loopback, e.g. --test-params "guest_loopback=l2fwd" # For 2 VNFs you may use ['testpmd', 'l2fwd'] -GUEST_LOOPBACK = ['testpmd', 'testpmd', \ - 'testpmd', 'testpmd', \ - 'testpmd', 'testpmd'] +GUEST_LOOPBACK = ['testpmd'] # username for guest image -GUEST_USERNAME = 'root' +GUEST_USERNAME = ['root'] # password for guest image -GUEST_PASSWORD = 'root' +GUEST_PASSWORD = ['root'] # login username prompt for guest image -GUEST_PROMPT_LOGIN = '.* login:' +GUEST_PROMPT_LOGIN = ['.* login:'] # login password prompt for guest image -GUEST_PROMPT_PASSWORD = 'Password: ' +GUEST_PROMPT_PASSWORD = ['Password: '] # standard prompt for guest image -GUEST_PROMPT = 'root.*#' +GUEST_PROMPT = ['root.*#'] -# log file for qemu -LOG_FILE_QEMU = 'qemu.log' +# defines the number of NICs configured for each guest, it must be less or equal to +# the number of NICs configured in GUEST_NICS +GUEST_NICS_NR = [2] -# log file for all commands executed on guest(s) -# multiple guests will result in log files with the guest number appended -LOG_FILE_GUEST_CMDS = 'guest-cmds.log' +# template for guests with 4 NICS, but only GUEST_NICS_NR NICS will be configured at runtime +GUEST_NICS = [[{'device' : 'eth0', 'mac' : '#MAC(00:00:00:00:00:01,2)', 'pci' : '00:04.0', 'ip' : '#IP(192.168.1.2,4)/24'}, + {'device' : 'eth1', 'mac' : '#MAC(00:00:00:00:00:02,2)', 'pci' : '00:05.0', 'ip' : '#IP(192.168.1.3,4)/24'}, + {'device' : 'eth2', 'mac' : '#MAC(cc:00:00:00:00:01,2)', 'pci' : '00:06.0', 'ip' : '#IP(192.168.1.4,4)/24'}, + {'device' : 'eth3', 'mac' : '#MAC(cc:00:00:00:00:02,2)', 'pci' : '00:07.0', 'ip' : '#IP(192.168.1.5,4)/24'}, + ]] -# ############################ -# Executables -# ############################ - -QEMU_BIN = os.path.join(QEMU_DIR, 'x86_64-softmmu/qemu-system-x86_64') - -# For 2 VNFs you may use ['eth0', 'eth2'] -GUEST_NIC1_NAME = ['eth0', 'eth0', 'eth0', 'eth0', 'eth0', 'eth0'] -GUEST_NIC2_NAME = ['eth1', 'eth1', 'eth1', 'eth1', 'eth1', 'eth1'] - -# For 2 VNFs you may use ['00:00:00:00:00:01', '00:00:00:00:00:03'] -GUEST_NET1_MAC = ['00:00:00:00:00:01', '00:00:00:00:00:03', \ - '00:00:00:00:00:05', '00:00:00:00:00:07', \ - '00:00:00:00:00:09', '00:00:00:00:00:0b'] -GUEST_NET2_MAC = ['00:00:00:00:00:02', '00:00:00:00:00:04', \ - '00:00:00:00:00:06', '00:00:00:00:00:08', \ - '00:00:00:00:00:0a', '00:00:00:00:00:0c'] - -# For 2 VNFs you may use ['00:04.0', '00:04.0'] -GUEST_NET1_PCI_ADDRESS = ['00:04.0', '00:04.0', \ - '00:04.0', '00:04.0', \ - '00:04.0', '00:04.0'] -GUEST_NET2_PCI_ADDRESS = ['00:05.0', '00:05.0', \ - '00:05.0', '00:05.0', \ - '00:05.0', '00:05.0'] - -GUEST_MEMORY = ['4096', '4096', '2048', '2048', '2048', '2048'] +# amount of host memory allocated for each guest +GUEST_MEMORY = ['2048'] +# number of hugepages configured inside each guest +GUEST_HUGEPAGES_NR = ['1024'] # test-pmd requires 2 VM cores -GUEST_SMP = ['2', '2', '2', '2', '2', '2'] +GUEST_SMP = ['2'] # Host cores to use to affinitize the SMP cores of a QEMU instance # For 2 VNFs you may use [(4,5), (6, 7)] -GUEST_CORE_BINDING = [(6, 7), (9, 10), (11, 12), (13, 14), (15, 16), (17, 18)] +GUEST_CORE_BINDING = [('#EVAL(6+2*#VMINDEX)', '#EVAL(7+2*#VMINDEX)')] # Queues per NIC inside guest for multi-queue configuration, requires switch # multi-queue to be enabled for dpdk. Set to 0 for disabled. Can be enabled if # using Vanilla OVS without enabling switch multi-queue. -GUEST_NIC_QUEUES = 0 +GUEST_NIC_QUEUES = [0] # Virtio-Net vhost thread CPU mapping. If using vanilla OVS with virtio-net, # you can affinitize the vhost-net threads by enabling the below setting. There @@ -131,22 +148,11 @@ GUEST_NIC_QUEUES = 0 VSWITCH_VHOST_NET_AFFINITIZATION = False VSWITCH_VHOST_CPU_MAP = [4,5,8,11] -GUEST_START_TIMEOUT = 120 -GUEST_OVS_DPDK_DIR = '/root/ovs_dpdk' -OVS_DPDK_SHARE = '/mnt/ovs_dpdk_share' - -# Set the CPU mask for testpmd loopback. To bind to specific guest CPUs use -l -# GUEST_TESTPMD_CPU_MASK = '-l 0,1' -GUEST_TESTPMD_CPU_MASK = '-c 0x3' - -# Testpmd multi-core config. Leave at 0's for disabled. Will not enable unless -# GUEST_NIC_QUEUES are > 0. For bi directional traffic NB_CORES must be equal -# to (RXQ + TXQ). -GUEST_TESTPMD_NB_CORES = 0 -GUEST_TESTPMD_TXQ = 0 -GUEST_TESTPMD_RXQ = 0 +GUEST_START_TIMEOUT = [120] +GUEST_OVS_DPDK_DIR = ['/root/ovs_dpdk'] +GUEST_OVS_DPDK_SHARE = ['/mnt/ovs_dpdk_share'] -# IP addresses to use for Vanilla OVS PVP testing +# IP addresses to use for Vanilla OVS PXP testing # Consider using RFC 2544/3330 recommended IP addresses for benchmark testing. # Network: 198.18.0.0/15 # Netmask: 255.254.0.0 @@ -163,15 +169,25 @@ VANILLA_TGEN_PORT1_MAC = 'AA:BB:CC:DD:EE:FF' VANILLA_TGEN_PORT2_IP = '1.1.2.10' VANILLA_TGEN_PORT2_MAC = 'AA:BB:CC:DD:EE:F0' -VANILLA_BRIDGE_IP = ['1.1.1.5/16', '1.1.1.6/16', \ - '1.1.1.7/16', '1.1.1.8/16', \ - '1.1.1.9/16', '1.1.1.10/16'] +GUEST_BRIDGE_IP = ['#IP(1.1.1.5)/16'] + +# ############################ +# Guest TESTPMD configuration +# ############################ + +# packet forwarding mode supported by testpmd; Please see DPDK documentation +# for comprehensive list of modes supported by your version. +# e.g. io|mac|mac_retry|macswap|flowgen|rxonly|txonly|csum|icmpecho|... +# Note: Option "mac_retry" has been changed to "mac retry" since DPDK v16.07 +GUEST_TESTPMD_FWD_MODE = ['csum'] -VANILLA_NIC1_IP_CIDR = ['192.168.1.2/24', '192.168.1.4/24', \ - '192.168.1.6/24', '192.168.1.8/24', \ - '192.168.1.10/24', '192.168.1.12/24'] -VANILLA_NIC2_IP_CIDR = ['192.168.1.3/24', '192.168.1.5/24', \ - '192.168.1.7/24', '192.168.1.9/24', \ - '192.168.1.11/24', '192.168.1.13/24'] +# Set the CPU mask for testpmd loopback. To bind to specific guest CPUs use -l +# GUEST_TESTPMD_CPU_MASK = ['-l 0,1'] +GUEST_TESTPMD_CPU_MASK = ['-c 0x3'] -VNF_AFFINITIZATION_ON = True +# Testpmd multi-core config. Leave at 0's for disabled. Will not enable unless +# GUEST_NIC_QUEUES are > 0. For bi directional traffic NB_CORES must be equal +# to (RXQ + TXQ). +GUEST_TESTPMD_NB_CORES = [0] +GUEST_TESTPMD_TXQ = [0] +GUEST_TESTPMD_RXQ = [0] diff --git a/conf/__init__.py b/conf/__init__.py index 46228235..88e8cec6 100644 --- a/conf/__init__.py +++ b/conf/__init__.py @@ -1,4 +1,4 @@ -# Copyright 2015 Intel Corporation. +# Copyright 2015-2016 Intel Corporation. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. @@ -22,7 +22,22 @@ and any user provided settings file. import os import re +import logging import pprint +import ast +import netaddr + +_LOGGER = logging.getLogger(__name__) + +# regex to parse configuration macros from 04_vnf.conf +# it will select all patterns starting with # sign +# and returns macro parameters and step +# examples of valid macros: +# #VMINDEX +# #MAC(AA:BB:CC:DD:EE:FF) or #MAC(AA:BB:CC:DD:EE:FF,2) +# #IP(192.168.1.2) or #IP(192.168.1.2,2) +# #EVAL(2*#VMINDEX) +_PARSE_PATTERN = r'(#[A-Z]+)(\(([^(),]+)(,([0-9]+))?\))?' class Settings(object): """Holding class for settings. @@ -121,6 +136,64 @@ class Settings(object): for key in os.environ: setattr(self, key, os.environ[key]) + def check_vm_settings(self, vm_number): + """ + Check all VM related settings starting with GUEST_ prefix. + If it is not available for defined number of VMs, then vsperf + will try to expand it automatically. Expansion is performed + also in case that first list item contains a macro. + """ + for key in self.__dict__: + if key.startswith('GUEST_'): + if (isinstance(self.__dict__[key], str) and + self.__dict__[key].find('#') >= 0): + self.__dict__[key] = [self.__dict__[key]] + self._expand_vm_settings(key, 1) + self.__dict__[key] = self.__dict__[key][0] + + if isinstance(self.__dict__[key], list): + if (len(self.__dict__[key]) < vm_number or + str(self.__dict__[key][0]).find('#') >= 0): + # expand configuration for all VMs + self._expand_vm_settings(key, vm_number) + + def _expand_vm_settings(self, key, vm_number): + """ + Expand VM option with given key for given number of VMs + """ + master_value = self.__dict__[key][0] + master_value_str = str(master_value) + if master_value_str.find('#') >= 0: + self.__dict__[key] = [] + for vmindex in range(vm_number): + value = master_value_str.replace('#VMINDEX', str(vmindex)) + for macro, args, param, _, step in re.findall(_PARSE_PATTERN, value): + multi = int(step) if len(step) and int(step) else 1 + if macro == '#EVAL': + tmp_result = str(eval(param)) + elif macro == '#MAC': + mac_value = netaddr.EUI(param).value + mac = netaddr.EUI(mac_value + vmindex * multi) + mac.dialect = netaddr.mac_unix_expanded + tmp_result = str(mac) + elif macro == '#IP': + ip_value = netaddr.IPAddress(param).value + tmp_result = str(netaddr.IPAddress(ip_value + vmindex * multi)) + else: + raise RuntimeError('Unknown configuration macro {} in {}'.format(macro, key)) + + value = value.replace("{}{}".format(macro, args), tmp_result) + + # retype value to original type if needed + if not isinstance(master_value, str): + value = ast.literal_eval(value) + self.__dict__[key].append(value) + else: + for vmindex in range(len(self.__dict__[key]), vm_number): + self.__dict__[key].append(master_value) + + _LOGGER.debug("Expanding option: %s = %s", key, self.__dict__[key]) + def __str__(self): """Provide settings as a human-readable string. diff --git a/core/component_factory.py b/core/component_factory.py index 258b7232..7f453bd2 100644 --- a/core/component_factory.py +++ b/core/component_factory.py @@ -18,8 +18,7 @@ from core.traffic_controller_rfc2544 import TrafficControllerRFC2544 from core.vswitch_controller_clean import VswitchControllerClean from core.vswitch_controller_p2p import VswitchControllerP2P -from core.vswitch_controller_pvp import VswitchControllerPVP -from core.vswitch_controller_pvvp import VswitchControllerPVVP +from core.vswitch_controller_pxp import VswitchControllerPXP from core.vswitch_controller_op2p import VswitchControllerOP2P from core.vswitch_controller_ptunp import VswitchControllerPtunP from core.vnf_controller import VnfController @@ -57,7 +56,7 @@ def create_vswitch(deployment_scenario, vswitch_class, traffic, The returned controller is configured with the given vSwitch class. - Deployment scenarios: 'p2p', 'pvp' + Deployment scenarios: e.g. 'p2p', 'pvp', 'pvpv12', etc. :param deployment_scenario: The deployment scenario name :param vswitch_class: Reference to vSwitch class to be used. @@ -66,18 +65,22 @@ def create_vswitch(deployment_scenario, vswitch_class, traffic, :return: IVSwitchController for the deployment_scenario """ deployment_scenario = deployment_scenario.lower() - if deployment_scenario.find("p2p") == 0: + if deployment_scenario.startswith("p2p"): return VswitchControllerP2P(vswitch_class, traffic) - elif deployment_scenario.find("pvp") >= 0: - return VswitchControllerPVP(vswitch_class, traffic) - elif deployment_scenario.find("pvvp") >= 0: - return VswitchControllerPVVP(vswitch_class, traffic) - elif deployment_scenario.find("op2p") >= 0: + elif deployment_scenario.startswith("pvp"): + return VswitchControllerPXP(deployment_scenario, vswitch_class, traffic) + elif deployment_scenario.startswith("pvvp"): + return VswitchControllerPXP(deployment_scenario, vswitch_class, traffic) + elif deployment_scenario.startswith("pvpv"): + return VswitchControllerPXP(deployment_scenario, vswitch_class, traffic) + elif deployment_scenario.startswith("op2p"): return VswitchControllerOP2P(vswitch_class, traffic, tunnel_operation) - elif deployment_scenario.find("ptunp") >= 0: + elif deployment_scenario.startswith("ptunp"): return VswitchControllerPtunP(vswitch_class, traffic) - elif deployment_scenario.find("clean") >= 0: + elif deployment_scenario.startswith("clean"): return VswitchControllerClean(vswitch_class, traffic) + else: + raise RuntimeError("Unknown deployment scenario '{}'.".format(deployment_scenario)) def create_vnf(deployment_scenario, vnf_class): diff --git a/core/vnf_controller.py b/core/vnf_controller.py index 8800ccaf..3e472f04 100644 --- a/core/vnf_controller.py +++ b/core/vnf_controller.py @@ -16,6 +16,7 @@ import logging import pexpect +from conf import settings from vnfs.vnf.vnf import IVnf class VnfController(object): @@ -25,13 +26,13 @@ class VnfController(object): Attributes: _vnf_class: A class object representing the VNF to be used. - _deployment_scenario: A string describing the scenario to set-up in the + _deployment: A string describing the scenario to set-up in the constructor. _vnfs: A list of vnfs controlled by the controller. """ - def __init__(self, deployment_scenario, vnf_class): - """Sets up the VNF infrastructure for the PVP deployment scenario. + def __init__(self, deployment, vnf_class): + """Sets up the VNF infrastructure based on deployment scenario :param vnf_class: The VNF class to be used. """ @@ -41,17 +42,39 @@ class VnfController(object): # setup controller with requested number of VNFs self._logger = logging.getLogger(__name__) self._vnf_class = vnf_class - self._deployment_scenario = deployment_scenario.upper() - if self._deployment_scenario == 'P2P': - self._vnfs = [] - elif self._deployment_scenario == 'PVP': - self._vnfs = [vnf_class()] - elif self._deployment_scenario == 'PVVP': - self._vnfs = [vnf_class(), vnf_class()] - elif self._deployment_scenario == 'OP2P': - self._vnfs = [] + self._deployment = deployment.lower() + self._vnfs = [] + if self._deployment == 'pvp': + vm_number = 1 + elif (self._deployment.startswith('pvvp') or + self._deployment.startswith('pvpv')): + if len(self._deployment) > 4: + vm_number = int(self._deployment[4:]) + else: + vm_number = 2 else: - self._vnfs = [] + # VnfController is created for all deployments, including deployments + # without VNFs like p2p + vm_number = 0 + + if vm_number: + self._logger.debug('Check configuration for %s guests.', vm_number) + settings.check_vm_settings(vm_number) + # enforce that GUEST_NIC_NR is 1 or even number of NICs + updated = False + nics_nr = settings.getValue('GUEST_NICS_NR') + for index in range(len(nics_nr)): + if nics_nr[index] > 1 and nics_nr[index] % 2: + updated = True + nics_nr[index] = int(nics_nr[index] / 2) * 2 + if updated: + settings.setValue('GUEST_NICS_NR', nics_nr) + self._logger.warning('Odd number of NICs was detected. Configuration ' + 'was updated to GUEST_NICS_NR = %s', + settings.getValue('GUEST_NICS_NR')) + + self._vnfs = [vnf_class() for _ in range(vm_number)] + self._logger.debug('__init__ ' + str(len(self._vnfs)) + ' VNF[s] with ' + ' '.join(map(str, self._vnfs))) @@ -62,6 +85,13 @@ class VnfController(object): ' VNF[s] with ' + ' '.join(map(str, self._vnfs))) return self._vnfs + def get_vnfs_number(self): + """Returns a number of vnfs controlled by this controller. + """ + self._logger.debug('get_vnfs_number ' + str(len(self._vnfs)) + + ' VNF[s]') + return len(self._vnfs) + def start(self): """Boots all VNFs set-up by __init__. diff --git a/core/vswitch_controller_pvp.py b/core/vswitch_controller_pvp.py deleted file mode 100644 index a4f61961..00000000 --- a/core/vswitch_controller_pvp.py +++ /dev/null @@ -1,118 +0,0 @@ -# Copyright 2015 Intel Corporation. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -"""VSwitch controller for Physical to VM to Physical deployment -""" - -import logging - -from core.vswitch_controller import IVswitchController -from vswitches.utils import add_ports_to_flow -from conf import settings - -_FLOW_TEMPLATE = { - 'idle_timeout': '0' -} - -class VswitchControllerPVP(IVswitchController): - """VSwitch controller for PVP deployment scenario. - - Attributes: - _vswitch_class: The vSwitch class to be used. - _vswitch: The vSwitch object controlled by this controller - _deployment_scenario: A string describing the scenario to set-up in the - constructor. - """ - def __init__(self, vswitch_class, traffic): - """Initializes up the prerequisites for the PVP deployment scenario. - - :vswitch_class: the vSwitch class to be used. - """ - self._logger = logging.getLogger(__name__) - self._vswitch_class = vswitch_class - self._vswitch = vswitch_class() - self._deployment_scenario = "PVP" - self._traffic = traffic.copy() - self._logger.debug('Creation using ' + str(self._vswitch_class)) - - def setup(self): - """ Sets up the switch for pvp - """ - self._logger.debug('Setup using ' + str(self._vswitch_class)) - - try: - self._vswitch.start() - - bridge = settings.getValue('VSWITCH_BRIDGE_NAME') - self._vswitch.add_switch(bridge) - - (_, phy1_number) = self._vswitch.add_phy_port(bridge) - (_, phy2_number) = self._vswitch.add_phy_port(bridge) - (_, vport1_number) = self._vswitch.add_vport(bridge) - (_, vport2_number) = self._vswitch.add_vport(bridge) - - self._vswitch.del_flow(bridge) - - # configure flows according to the TC definition - flow_template = _FLOW_TEMPLATE.copy() - if self._traffic['flow_type'] == 'IP': - flow_template.update({'dl_type':'0x0800', 'nw_src':self._traffic['l3']['srcip'], - 'nw_dst':self._traffic['l3']['dstip']}) - - flow1 = add_ports_to_flow(flow_template, phy1_number, - vport1_number) - flow2 = add_ports_to_flow(flow_template, vport2_number, - phy2_number) - self._vswitch.add_flow(bridge, flow1) - self._vswitch.add_flow(bridge, flow2) - - if self._traffic['bidir'] == 'True': - flow3 = add_ports_to_flow(flow_template, phy2_number, - vport2_number) - flow4 = add_ports_to_flow(flow_template, vport1_number, - phy1_number) - self._vswitch.add_flow(bridge, flow3) - self._vswitch.add_flow(bridge, flow4) - - except: - self._vswitch.stop() - raise - - def stop(self): - """Tears down the switch created in setup(). - """ - self._logger.debug('Stop using ' + str(self._vswitch_class)) - self._vswitch.stop() - - def __enter__(self): - self.setup() - - def __exit__(self, type_, value, traceback): - self.stop() - - def get_vswitch(self): - """See IVswitchController for description - """ - return self._vswitch - - def get_ports_info(self): - """See IVswitchController for description - """ - self._logger.debug('get_ports_info using ' + str(self._vswitch_class)) - return self._vswitch.get_ports(settings.getValue('VSWITCH_BRIDGE_NAME')) - - def dump_vswitch_flows(self): - """See IVswitchController for description - """ - self._vswitch.dump_flows(settings.getValue('VSWITCH_BRIDGE_NAME')) diff --git a/core/vswitch_controller_pvvp.py b/core/vswitch_controller_pvvp.py deleted file mode 100644 index 729aca3f..00000000 --- a/core/vswitch_controller_pvvp.py +++ /dev/null @@ -1,126 +0,0 @@ -# Copyright 2015 Intel Corporation. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -"""VSwitch controller for Physical to VM to Physical deployment -""" - -import logging - -from core.vswitch_controller import IVswitchController -from vswitches.utils import add_ports_to_flow -from conf import settings - -_FLOW_TEMPLATE = { - 'idle_timeout': '0' -} - -class VswitchControllerPVVP(IVswitchController): - """VSwitch controller for PVVP deployment scenario. - - Attributes: - _vswitch_class: The vSwitch class to be used. - _vswitch: The vSwitch object controlled by this controller - _deployment_scenario: A string describing the scenario to set-up in the - constructor. - """ - def __init__(self, vswitch_class, traffic): - """Initializes up the prerequisites for the PVVP deployment scenario. - - :vswitch_class: the vSwitch class to be used. - """ - self._logger = logging.getLogger(__name__) - self._vswitch_class = vswitch_class - self._vswitch = vswitch_class() - self._deployment_scenario = "PVVP" - self._traffic = traffic.copy() - self._logger.debug('Creation using ' + str(self._vswitch_class)) - - def setup(self): - """ Sets up the switch for PVVP - """ - self._logger.debug('Setup using ' + str(self._vswitch_class)) - - try: - self._vswitch.start() - - bridge = settings.getValue('VSWITCH_BRIDGE_NAME') - self._vswitch.add_switch(bridge) - - (_, phy1_number) = self._vswitch.add_phy_port(bridge) - (_, phy2_number) = self._vswitch.add_phy_port(bridge) - (_, vport1_number) = self._vswitch.add_vport(bridge) - (_, vport2_number) = self._vswitch.add_vport(bridge) - (_, vport3_number) = self._vswitch.add_vport(bridge) - (_, vport4_number) = self._vswitch.add_vport(bridge) - - self._vswitch.del_flow(bridge) - - # configure flows according to the TC definition - flow_template = _FLOW_TEMPLATE.copy() - if self._traffic['flow_type'] == 'IP': - flow_template.update({'dl_type':'0x0800', 'nw_src':self._traffic['l3']['srcip'], - 'nw_dst':self._traffic['l3']['dstip']}) - - flow1 = add_ports_to_flow(flow_template, phy1_number, - vport1_number) - flow2 = add_ports_to_flow(flow_template, vport2_number, - vport3_number) - flow3 = add_ports_to_flow(flow_template, vport4_number, - phy2_number) - self._vswitch.add_flow(bridge, flow1) - self._vswitch.add_flow(bridge, flow2) - self._vswitch.add_flow(bridge, flow3) - - if self._traffic['bidir'] == 'True': - flow4 = add_ports_to_flow(flow_template, phy2_number, - vport4_number) - flow5 = add_ports_to_flow(flow_template, vport3_number, - vport2_number) - flow6 = add_ports_to_flow(flow_template, vport1_number, - phy1_number) - self._vswitch.add_flow(bridge, flow4) - self._vswitch.add_flow(bridge, flow5) - self._vswitch.add_flow(bridge, flow6) - - except: - self._vswitch.stop() - raise - - def stop(self): - """Tears down the switch created in setup(). - """ - self._logger.debug('Stop using ' + str(self._vswitch_class)) - self._vswitch.stop() - - def __enter__(self): - self.setup() - - def __exit__(self, type_, value, traceback): - self.stop() - - def get_vswitch(self): - """See IVswitchController for description - """ - return self._vswitch - - def get_ports_info(self): - """See IVswitchController for description - """ - self._logger.debug('get_ports_info using ' + str(self._vswitch_class)) - return self._vswitch.get_ports(settings.getValue('VSWITCH_BRIDGE_NAME')) - - def dump_vswitch_flows(self): - """See IVswitchController for description - """ - self._vswitch.dump_flows(settings.getValue('VSWITCH_BRIDGE_NAME')) diff --git a/core/vswitch_controller_pxp.py b/core/vswitch_controller_pxp.py new file mode 100644 index 00000000..6f53b5ac --- /dev/null +++ b/core/vswitch_controller_pxp.py @@ -0,0 +1,221 @@ +# Copyright 2016 Intel Corporation. +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +"""VSwitch controller for multi VM scenarios with serial or parallel connection +""" + +import logging +import netaddr + +from core.vswitch_controller import IVswitchController +from vswitches.utils import add_ports_to_flow +from conf import settings + +_FLOW_TEMPLATE = { + 'idle_timeout': '0' +} + +_PROTO_TCP = 6 +_PROTO_UDP = 17 + +class VswitchControllerPXP(IVswitchController): + """VSwitch controller for PXP deployment scenario. + """ + def __init__(self, deployment, vswitch_class, traffic): + """Initializes up the prerequisites for the PXP deployment scenario. + + :vswitch_class: the vSwitch class to be used. + :deployment: the deployment scenario to configure + :traffic: dictionary with detailed traffic definition + """ + self._logger = logging.getLogger(__name__) + self._vswitch_class = vswitch_class + self._vswitch = vswitch_class() + self._pxp_topology = 'parallel' if deployment.startswith('pvpv') else 'serial' + if deployment == 'pvp': + self._pxp_vm_count = 1 + elif deployment.startswith('pvvp') or deployment.startswith('pvpv'): + if len(deployment) > 4: + self._pxp_vm_count = int(deployment[4:]) + else: + self._pxp_vm_count = 2 + else: + raise RuntimeError('Unknown number of VMs involved in {} deployment.'.format(deployment)) + + self._deployment_scenario = deployment + + self._traffic = traffic.copy() + self._bidir = True if self._traffic['bidir'] == 'True' else False + self._logger.debug('Creation using ' + str(self._vswitch_class)) + self._bridge = settings.getValue('VSWITCH_BRIDGE_NAME') + + def setup(self): + """ Sets up the switch for PXP + """ + self._logger.debug('Setup using ' + str(self._vswitch_class)) + + try: + self._vswitch.start() + + self._vswitch.add_switch(self._bridge) + + # create physical ports + (_, phy1_number) = self._vswitch.add_phy_port(self._bridge) + (_, phy2_number) = self._vswitch.add_phy_port(self._bridge) + + # create VM ports + # initialize vport array to requested number of VMs + guest_nics = settings.getValue('GUEST_NICS_NR') + vm_ports = [[] for _ in range(self._pxp_vm_count)] + # create as many VM ports as requested by configuration, but configure + # only even number of NICs or just one + for vmindex in range(self._pxp_vm_count): + # just for case, enforce even number of NICs or 1 + nics_nr = int(guest_nics[vmindex] / 2) * 2 if guest_nics[vmindex] > 1 else 1 + self._logger.debug('Create %s vports for %s. VM with index %s', + nics_nr, vmindex + 1, vmindex) + for _ in range(nics_nr): + (_, vport) = self._vswitch.add_vport(self._bridge) + vm_ports[vmindex].append(vport) + + self._vswitch.del_flow(self._bridge) + + # configure flows according to the TC definition + if self._pxp_topology == 'serial': + flow = _FLOW_TEMPLATE.copy() + if self._traffic['flow_type'] == 'IP': + flow.update({'dl_type':'0x0800', + 'nw_src':self._traffic['l3']['srcip'], + 'nw_dst':self._traffic['l3']['dstip']}) + + # insert flows for phy ports first + # from 1st PHY to 1st vport of 1st VM + self._add_flow(flow, + phy1_number, + vm_ports[0][0], + self._bidir) + # from last vport of last VM to 2nd phy + self._add_flow(flow, + vm_ports[self._pxp_vm_count-1][-1], + phy2_number, + self._bidir) + + # add serial connections among VMs and VM NICs pairs if needed + # in case of multiple NICs pairs per VM, the pairs are chained + # first, before flow to the next VM is created + for vmindex in range(self._pxp_vm_count): + # connect VMs NICs pairs in case of 4 and more NICs per VM + connections = [(vm_ports[vmindex][2*(x+1)-1], + vm_ports[vmindex][2*(x+1)]) + for x in range(int(len(vm_ports[vmindex])/2)-1)] + for connection in connections: + self._add_flow(flow, + connection[0], + connection[1], + self._bidir) + # connect last NICs to the next VM if there is any + if self._pxp_vm_count > vmindex + 1: + self._add_flow(flow, + vm_ports[vmindex][-1], + vm_ports[vmindex+1][0], + self._bidir) + else: + proto = _PROTO_TCP if self._traffic['l3']['proto'].lower() == 'tcp' else _PROTO_UDP + dst_mac_value = netaddr.EUI(self._traffic['l2']['dstmac']).value + dst_ip_value = netaddr.IPAddress(self._traffic['l3']['dstip']).value + # initialize stream index; every NIC pair of every VM uses unique stream + stream = 0 + for vmindex in range(self._pxp_vm_count): + # iterate through all VMs NIC pairs... + if len(vm_ports[vmindex]) > 1: + port_pairs = [(vm_ports[vmindex][2*x], + vm_ports[vmindex][2*x+1]) for x in range(int(len(vm_ports[vmindex])/2))] + else: + # ...or connect VM with just one NIC to both phy ports + port_pairs = [(vm_ports[vmindex][0], vm_ports[vmindex][0])] + + for port_pair in port_pairs: + flow_p = _FLOW_TEMPLATE.copy() + flow_v = _FLOW_TEMPLATE.copy() + + # update flow based on trafficgen settings + if self._traffic['stream_type'] == 'L2': + tmp_mac = netaddr.EUI(dst_mac_value + stream) + tmp_mac.dialect = netaddr.mac_unix_expanded + flow_p.update({'dl_dst':tmp_mac}) + elif self._traffic['stream_type'] == 'L3': + tmp_ip = netaddr.IPAddress(dst_ip_value + stream) + flow_p.update({'dl_type':'0x800', 'nw_dst':tmp_ip}) + elif self._traffic['stream_type'] == 'L4': + flow_p.update({'dl_type':'0x800', 'nw_proto':proto, 'tp_dst':stream}) + else: + raise RuntimeError('Unknown stream_type {}'.format(self._traffic['stream_type'])) + + # insert flow to dispatch traffic from physical ports + # to VMs based on stream type; all traffic from VMs is + # sent to physical ports to avoid issues with MAC swapping + # and upper layer mods performed inside guests + self._add_flow(flow_p, phy1_number, port_pair[0]) + self._add_flow(flow_v, port_pair[1], phy2_number) + if self._bidir: + self._add_flow(flow_p, phy2_number, port_pair[1]) + self._add_flow(flow_v, port_pair[0], phy1_number) + + # every NIC pair needs its own unique traffic stream + stream += 1 + + except: + self._vswitch.stop() + raise + + def stop(self): + """Tears down the switch created in setup(). + """ + self._logger.debug('Stop using ' + str(self._vswitch_class)) + self._vswitch.stop() + + def _add_flow(self, flow, port1, port2, reverse_flow=False): + """ Helper method to insert flow into the vSwitch + """ + self._vswitch.add_flow(self._bridge, + add_ports_to_flow(flow, + port1, + port2)) + if reverse_flow: + self._vswitch.add_flow(self._bridge, + add_ports_to_flow(flow, + port2, + port1)) + + def __enter__(self): + self.setup() + + def __exit__(self, type_, value, traceback): + self.stop() + + def get_vswitch(self): + """See IVswitchController for description + """ + return self._vswitch + + def get_ports_info(self): + """See IVswitchController for description + """ + self._logger.debug('get_ports_info using ' + str(self._vswitch_class)) + return self._vswitch.get_ports(self._bridge) + + def dump_vswitch_flows(self): + """See IVswitchController for description + """ + self._vswitch.dump_flows(self._bridge) diff --git a/docs/configguide/installation.rst b/docs/configguide/installation.rst index eeefe75d..2f3faaeb 100755 --- a/docs/configguide/installation.rst +++ b/docs/configguide/installation.rst @@ -169,12 +169,12 @@ hugepage amounts to support running these configurations. It is recommended to configure 1GB hugepages as the pagesize. The amount of hugepages needed depends on your configuration files in vsperf. -Each guest image requires 4096 MB by default according to the default settings +Each guest image requires 2048 MB by default according to the default settings in the ``04_vnf.conf`` file. .. code:: bash - GUEST_MEMORY = ['4096', '4096'] + GUEST_MEMORY = ['2048'] The dpdk startup parameters also require an amount of hugepages depending on your configuration in the ``02_vswitch.conf`` file. diff --git a/docs/design/vswitchperf_design.rst b/docs/design/vswitchperf_design.rst index e61b3ea6..cdf9f318 100755 --- a/docs/design/vswitchperf_design.rst +++ b/docs/design/vswitchperf_design.rst @@ -34,7 +34,7 @@ List all the cli options: $ ./vsperf -h -Run all tests that have ``tput`` in their name - ``p2p_tput``, ``pvp_tput`` etc.: +Run all tests that have ``tput`` in their name - ``phy2phy_tput``, ``pvp_tput`` etc.: .. code-block:: console @@ -100,12 +100,305 @@ The values in the file specified by ``--conf-file`` takes precedence over all the other configuration files and does not have to follow the naming convention. +Configuration of GUEST options +------------------------------ + +VSPERF is able to setup scenarios involving a number of VMs in series or in parallel. +All configuration options related to a particular VM instance are defined as +lists and prefixed with ``GUEST_`` label. It is essential, that there is enough +items in all ``GUEST_`` options to cover all VM instances involved in the test. +In case there is not enough items, then VSPERF will use the first item of +particular ``GUEST_`` option to expand the list to required length. + +Example of option expansion for 4 VMs: + + .. code-block:: python + + """ + Original values: + """ + GUEST_SMP = ['2'] + GUEST_MEMORY = ['2048', '4096'] + + """ + Values after automatic expansion: + """ + GUEST_SMP = ['2', '2', '2', '2'] + GUEST_MEMORY = ['2048', '4096', '2048', '2048'] + + +First option can contain macros starting with ``#`` to generate VM specific values. +These macros can be used only for options of ``list`` or ``str`` types with ``GUEST_`` +prefix. + +Example of macros and their expnasion for 2 VMs: + + .. code-block:: python + + """ + Original values: + """ + GUEST_SHARE_DIR = ['/tmp/qemu#VMINDEX_share'] + GUEST_BRIDGE_IP = ['#IP(1.1.1.5)/16'] + + """ + Values after automatic expansion: + """ + GUEST_SHARE_DIR = ['/tmp/qemu0_share', '/tmp/qemu1_share'] + GUEST_BRIDGE_IP = ['1.1.1.5/16', '1.1.1.6/16'] + +Additional examples are available at ``04_vnf.conf``. + +Note: In case, that macro is detected in the first item of the list, then +all other items are ignored and list content is created automatically. + +Multiple macros can be used inside one configuration option definition, but macros +cannot be used inside other macros. The only exception is macro ``#VMINDEX``, which +is expanded first and thus it can be used inside other macros. + +Following macros are supported: + + * ``#VMINDEX`` - it is replaced by index of VM being executed; This macro + is expanded first, so it can be used inside other macros. + + Example: + + .. code-block:: python + + GUEST_SHARE_DIR = ['/tmp/qemu#VMINDEX_share'] + + * ``#MAC(mac_address[, step])`` - it will iterate given ``mac_address`` + with optional ``step``. In case that step is not defined, then it is set to 1. + It means, that first VM will use the value of ``mac_address``, second VM + value of ``mac_address`` increased by ``step``, etc. + + Example: + + .. code-block:: python + + GUEST_NICS = [[{'mac' : '#MAC(00:00:00:00:00:01,2)'}]] + + * ``#IP(ip_address[, step])`` - it will iterate given ``ip_address`` + with optional ``step``. In case that step is not defined, then it is set to 1. + It means, that first VM will use the value of ``ip_address``, second VM + value of ``ip_address`` increased by ``step``, etc. + + Example: + + .. code-block:: python + + GUEST_BRIDGE_IP = ['#IP(1.1.1.5)/16'] + + * ``#EVAL(expression)`` - it will evaluate given ``expression`` as python code; + Only simple expressions should be used. Call of the functions is not supported. + + Example: + + .. code-block:: python + + GUEST_CORE_BINDING = [('#EVAL(6+2*#VMINDEX)', '#EVAL(7+2*#VMINDEX)')] Other Configuration ------------------- ``conf.settings`` also loads configuration from the command line and from the environment. +PXP Deployment +============== + +Every testcase uses one of the supported deployment scenarios to setup test environment. +The controller responsible for a given scenario configures flows in the vswitch to route +traffic among physical interfaces connected to the traffic generator and virtual +machines. VSPERF supports several deployments including PXP deployment, which can +setup various scenarios with multiple VMs. + +These scenarios are realized by VswitchControllerPXP class, which can configure and +execute given number of VMs in serial or parallel configurations. Every VM can be +configured with just one or an even number of interfaces. In case that VM has more than +2 interfaces, then traffic is properly routed among pairs of interfaces. + +Example of traffic routing for VM with 4 NICs in serial configuration: + +.. code-block:: console + + +------------------------------------------+ + | VM with 4 NICs | + | +---------------+ +---------------+ | + | | Application | | Application | | + | +---------------+ +---------------+ | + | ^ | ^ | | + | | v | v | + | +---------------+ +---------------+ | + | | logical ports | | logical ports | | + | | 0 1 | | 2 3 | | + +--+---------------+----+---------------+--+ + ^ : ^ : + | | | | + : v : v + +-----------+---------------+----+---------------+----------+ + | vSwitch | 0 1 | | 2 3 | | + | | logical ports | | logical ports | | + | previous +---------------+ +---------------+ next | + | VM or PHY ^ | ^ | VM or PHY| + | port -----+ +------------+ +---> port | + +-----------------------------------------------------------+ + +It is also possible to define different number of interfaces for each VM to better +simulate real scenarios. + +Example of traffic routing for 2 VMs in serial configuration, where 1st VM has +4 NICs and 2nd VM 2 NICs: + +.. code-block:: console + + +------------------------------------------+ +---------------------+ + | 1st VM with 4 NICs | | 2nd VM with 2 NICs | + | +---------------+ +---------------+ | | +---------------+ | + | | Application | | Application | | | | Application | | + | +---------------+ +---------------+ | | +---------------+ | + | ^ | ^ | | | ^ | | + | | v | v | | | v | + | +---------------+ +---------------+ | | +---------------+ | + | | logical ports | | logical ports | | | | logical ports | | + | | 0 1 | | 2 3 | | | | 0 1 | | + +--+---------------+----+---------------+--+ +--+---------------+--+ + ^ : ^ : ^ : + | | | | | | + : v : v : v + +-----------+---------------+----+---------------+-------+---------------+----------+ + | vSwitch | 0 1 | | 2 3 | | 4 5 | | + | | logical ports | | logical ports | | logical ports | | + | previous +---------------+ +---------------+ +---------------+ next | + | VM or PHY ^ | ^ | ^ | VM or PHY| + | port -----+ +------------+ +---------------+ +----> port | + +-----------------------------------------------------------------------------------+ + +The number of VMs involved in the test and the type of their connection is defined +by deployment name as follows: + + * ``pvvp[number]`` - configures scenario with VMs connected in series with + optional ``number`` of VMs. In case that ``number`` is not specified, then + 2 VMs will be used. + + Example of 2 VMs in a serial configuration: + + .. code-block:: console + + +----------------------+ +----------------------+ + | 1st VM | | 2nd VM | + | +---------------+ | | +---------------+ | + | | Application | | | | Application | | + | +---------------+ | | +---------------+ | + | ^ | | | ^ | | + | | v | | | v | + | +---------------+ | | +---------------+ | + | | logical ports | | | | logical ports | | + | | 0 1 | | | | 0 1 | | + +---+---------------+--+ +---+---------------+--+ + ^ : ^ : + | | | | + : v : v + +---+---------------+---------+---------------+--+ + | | 0 1 | | 3 4 | | + | | logical ports | vSwitch | logical ports | | + | +---------------+ +---------------+ | + | ^ | ^ | | + | | +-----------------+ v | + | +----------------------------------------+ | + | | physical ports | | + | | 0 1 | | + +---+----------------------------------------+---+ + ^ : + | | + : v + +------------------------------------------------+ + | | + | traffic generator | + | | + +------------------------------------------------+ + + * ``pvpv[number]`` - configures scenario with VMs connected in parallel with + optional ``number`` of VMs. In case that ``number`` is not specified, then + 2 VMs will be used. Multistream feature is used to route traffic to particular + VMs (or NIC pairs of every VM). It means, that VSPERF will enable multistream + feaure and sets the number of streams to the number of VMs and their NIC + pairs. Traffic will be dispatched based on Stream Type, i.e. by UDP port, + IP address or MAC address. + + Example of 2 VMs in a parallel configuration, where traffic is dispatched + based on the UDP port. + + .. code-block:: console + + +----------------------+ +----------------------+ + | 1st VM | | 2nd VM | + | +---------------+ | | +---------------+ | + | | Application | | | | Application | | + | +---------------+ | | +---------------+ | + | ^ | | | ^ | | + | | v | | | v | + | +---------------+ | | +---------------+ | + | | logical ports | | | | logical ports | | + | | 0 1 | | | | 0 1 | | + +---+---------------+--+ +---+---------------+--+ + ^ : ^ : + | | | | + : v : v + +---+---------------+---------+---------------+--+ + | | 0 1 | | 3 4 | | + | | logical ports | vSwitch | logical ports | | + | +---------------+ +---------------+ | + | ^ | ^ : | + | | ......................: : | + | UDP | UDP : | : | + | port| port: +--------------------+ : | + | 0 | 1 : | : | + | | : v v | + | +----------------------------------------+ | + | | physical ports | | + | | 0 1 | | + +---+----------------------------------------+---+ + ^ : + | | + : v + +------------------------------------------------+ + | | + | traffic generator | + | | + +------------------------------------------------+ + + +PXP deployment is backward compatible with PVP deployment, where ``pvp`` is +an alias for ``pvvp1`` and it executes just one VM. + +The number of interfaces used by VMs is defined by configuration option +``GUEST_NICS_NR``. In case that more than one pair of interfaces is defined +for VM, then: + + * for ``pvvp`` (serial) scenario every NIC pair is connected in serial + before connection to next VM is created + * for ``pvpv`` (parallel) scenario every NIC pair is directly connected + to the physical ports and unique traffic stream is assigned to it + +Examples: + + * Deployment ``pvvp10`` will start 10 VMs and connects them in series + * Deployment ``pvpv4`` will start 4 VMs and connects them in parallel + * Deployment ``pvpv1`` and GUEST_NICS_NR = [4] will start 1 VM with + 4 interfaces and every NIC pair is directly connected to the + physical ports + * Deployment ``pvvp`` and GUEST_NICS_NR = [2, 4] will start 2 VMs; + 1st VM will have 2 interfaces and 2nd VM 4 interfaces. These interfaces + will be connected in serial, i.e. traffic will flow as follows: + PHY1 -> VM1_1 -> VM1_2 -> VM2_1 -> VM2_2 -> VM2_3 -> VM2_4 -> PHY2 + +Note: In case that only 1 or more than 2 NICs are configured for VM, +then ``testpmd`` should be used as forwarding application inside the VM. +As it is able to forward traffic between multiple VM NIC pairs. + +Note: In case of ``linux_bridge``, all NICs are connected to the same +bridge inside the VM. + VM, vSwitch, Traffic Generator Independence =========================================== @@ -198,7 +491,7 @@ and Forwarding Applications from other components. The controlled classes provide basic primitive operations. The Controllers sequence and co-ordinate these primitive operation in to useful actions. For -instance the vswitch_controller_PVP can be used to bring any vSwitch (that +instance the vswitch_controller_p2p can be used to bring any vSwitch (that implements the primitives defined in IVSwitch) into the configuration required by the Phy-to-Phy Deployment Scenario. diff --git a/docs/msc/vsperf.msc b/docs/msc/vsperf.msc index 4d2c6bad..aec53604 100755 --- a/docs/msc/vsperf.msc +++ b/docs/msc/vsperf.msc @@ -11,9 +11,9 @@ msc { vsperf => testcase [ label="run()" ]; --- [ label = " skipping details of finding and creating correct subclasses of IVSwitch, ITrafficGenerator etc." ]; testcase => vswitch_ctl [ label="create(vswitch_class" ]; - vswitch_ctl note vswitch_ctl [ label="vswitch_ctl is instance of VswitchControllerPvp"]; + vswitch_ctl note vswitch_ctl [ label="vswitch_ctl is instance of VswitchControllerPXP"]; testcase => vnf_ctl [ label="create(vnf_class)" ]; - vnf_ctl note vnf_ctl [ label="vnf_ctl is instance of VnfControllerPvp"]; + vnf_ctl note vnf_ctl [ label="vnf_ctl is instance of VnfController"]; testcase => traffic_ctl [ label="create()" ]; traffic_ctl note traffic_ctl [ label="traffic_ctl is instance of TrafficControllerRFC2544"]; |||; diff --git a/docs/requirements/ietf_draft/draft-ietf-bmwg-vswitch-opnfv-00.txt b/docs/requirements/ietf_draft/draft-ietf-bmwg-vswitch-opnfv-00.txt deleted file mode 100644 index 7fb0562b..00000000 --- a/docs/requirements/ietf_draft/draft-ietf-bmwg-vswitch-opnfv-00.txt +++ /dev/null @@ -1,1232 +0,0 @@ - - - - -Network Working Group M. Tahhan -Internet-Draft B. O'Mahony -Intended status: Informational Intel -Expires: January 9, 2017 A. Morton - AT&T Labs - July 8, 2016 - - - Benchmarking Virtual Switches in OPNFV - draft-ietf-bmwg-vswitch-opnfv-00 - -Abstract - - This memo describes the progress of the Open Platform for NFV (OPNFV) - project on virtual switch performance "VSWITCHPERF". This project - intends to build on the current and completed work of the - Benchmarking Methodology Working Group in IETF, by referencing - existing literature. The Benchmarking Methodology Working Group has - traditionally conducted laboratory characterization of dedicated - physical implementations of internetworking functions. Therefore, - this memo begins to describe the additional considerations when - virtual switches are implemented in general-purpose hardware. The - expanded tests and benchmarks are also influenced by the OPNFV - mission to support virtualization of the "telco" infrastructure. - -Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on January 9, 2017. - - - - -Tahhan, et al. Expires January 9, 2017 [Page 1] - -Internet-Draft Benchmarking vSwitches July 2016 - - -Copyright Notice - - Copyright (c) 2016 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Benchmarking Considerations . . . . . . . . . . . . . . . . . 4 - 3.1. Comparison with Physical Network Functions . . . . . . . 4 - 3.2. Continued Emphasis on Black-Box Benchmarks . . . . . . . 4 - 3.3. New Configuration Parameters . . . . . . . . . . . . . . 4 - 3.4. Flow classification . . . . . . . . . . . . . . . . . . . 6 - 3.5. Benchmarks using Baselines with Resource Isolation . . . 7 - 4. VSWITCHPERF Specification Summary . . . . . . . . . . . . . . 8 - 5. 3x3 Matrix Coverage . . . . . . . . . . . . . . . . . . . . . 16 - 5.1. Speed of Activation . . . . . . . . . . . . . . . . . . . 17 - 5.2. Accuracy of Activation section . . . . . . . . . . . . . 17 - 5.3. Reliability of Activation . . . . . . . . . . . . . . . . 17 - 5.4. Scale of Activation . . . . . . . . . . . . . . . . . . . 17 - 5.5. Speed of Operation . . . . . . . . . . . . . . . . . . . 17 - 5.6. Accuracy of Operation . . . . . . . . . . . . . . . . . . 17 - 5.7. Reliability of Operation . . . . . . . . . . . . . . . . 17 - 5.8. Scalability of Operation . . . . . . . . . . . . . . . . 18 - 5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 9.2. Informative References . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 - - - - - - - - -Tahhan, et al. Expires January 9, 2017 [Page 2] - -Internet-Draft Benchmarking vSwitches July 2016 - - -1. Introduction - - Benchmarking Methodology Working Group (BMWG) has traditionally - conducted laboratory characterization of dedicated physical - implementations of internetworking functions. The Black-box - Benchmarks of Throughput, Latency, Forwarding Rates and others have - served our industry for many years. Now, Network Function - Virtualization (NFV) has the goal to transform how internetwork - functions are implemented, and therefore has garnered much attention. - - This memo summarizes the progress of the Open Platform for NFV - (OPNFV) project on virtual switch performance characterization, - "VSWITCHPERF", through the Brahmaputra (second) release [BrahRel]. - This project intends to build on the current and completed work of - the Benchmarking Methodology Working Group in IETF, by referencing - existing literature. For example, currently the most often - referenced RFC is [RFC2544] (which depends on [RFC1242]) and - foundation of the benchmarking work in OPNFV is common and strong. - - See https://wiki.opnfv.org/ - characterize_vswitch_performance_for_telco_nfv_use_cases for more - background, and the OPNFV website for general information: - https://www.opnfv.org/ - - The authors note that OPNFV distinguishes itself from other open - source compute and networking projects through its emphasis on - existing "telco" services as opposed to cloud-computing. There are - many ways in which telco requirements have different emphasis on - performance dimensions when compared to cloud computing: support for - and transfer of isochronous media streams is one example. - - Note also that the move to NFV Infrastructure has resulted in many - new benchmarking initiatives across the industry. The authors are - currently doing their best to maintain alignment with many other - projects, and this Internet Draft is one part of the efforts. We - acknowledge the early work in - [I-D.huang-bmwg-virtual-network-performance], and useful discussion - with the authors. - -2. Scope - - The primary purpose and scope of the memo is to inform the industry - of work-in-progress that builds on the body of extensive BMWG - literature and experience, and describe the extensions needed for - benchmarking virtual switches. Inital feedback indicates that many - of these extensions may be applicable beyond the current scope (to - hardware switches in the NFV Infrastructure and to virtual routers, - for example). Additionally, this memo serves as a vehicle to include - - - -Tahhan, et al. Expires January 9, 2017 [Page 3] - -Internet-Draft Benchmarking vSwitches July 2016 - - - more detail and commentary from BMWG and other Open Source - communities, under BMWG's chartered work to characterize the NFV - Infrastructure (a virtual switch is an important aspect of that - infrastructure). - -3. Benchmarking Considerations - - This section highlights some specific considerations (from - [I-D.ietf-bmwg-virtual-net])related to Benchmarks for virtual - switches. The OPNFV project is sharing its present view on these - areas, as they develop their specifications in the Level Test Design - (LTD) document. - -3.1. Comparison with Physical Network Functions - - To compare the performance of virtual designs and implementations - with their physical counterparts, identical benchmarks are needed. - BMWG has developed specifications for many network functions this - memo re-uses existing benchmarks through references, and expands them - during development of new methods. A key configuration aspect is the - number of parallel cores required to achieve comparable performance - with a given physical device, or whether some limit of scale was - reached before the cores could achieve the comparable level. - - It's unlikely that the virtual switch will be the only application - running on the SUT, so CPU utilization, Cache utilization, and Memory - footprint should also be recorded for the virtual implementations of - internetworking functions. - -3.2. Continued Emphasis on Black-Box Benchmarks - - External observations remain essential as the basis for Benchmarks. - Internal observations with fixed specification and interpretation - will be provided in parallel to assist the development of operations - procedures when the technology is deployed. - -3.3. New Configuration Parameters - - A key consideration when conducting any sort of benchmark is trying - to ensure the consistency and repeatability of test results. When - benchmarking the performance of a vSwitch there are many factors that - can affect the consistency of results, one key factor is matching the - various hardware and software details of the SUT. This section lists - some of the many new parameters which this project believes are - critical to report in order to achieve repeatability. - - Hardware details including: - - - - -Tahhan, et al. Expires January 9, 2017 [Page 4] - -Internet-Draft Benchmarking vSwitches July 2016 - - - o Platform details - - o Processor details - - o Memory information (type and size) - - o Number of enabled cores - - o Number of cores used for the test - - o Number of physical NICs, as well as their details (manufacturer, - versions, type and the PCI slot they are plugged into) - - o NIC interrupt configuration - - o BIOS version, release date and any configurations that were - modified - - o CPU microcode level - - o Memory DIMM configurations (quad rank performance may not be the - same as dual rank) in size, freq and slot locations - - o PCI configuration parameters (payload size, early ack option...) - - o Power management at all levels (ACPI sleep states, processor - package, OS...) - - Software details including: - - o OS parameters and behavior (text vs graphical no one typing at the - console on one system) - - o OS version (for host and VNF) - - o Kernel version (for host and VNF) - - o GRUB boot parameters (for host and VNF) - - o Hypervisor details (Type and version) - - o Selected vSwitch, version number or commit id used - - o vSwitch launch command line if it has been parameterised - - o Memory allocation to the vSwitch - - o which NUMA node it is using, and how many memory channels - - - -Tahhan, et al. Expires January 9, 2017 [Page 5] - -Internet-Draft Benchmarking vSwitches July 2016 - - - o DPDK or any other SW dependency version number or commit id used - - o Memory allocation to a VM - if it's from Hugpages/elsewhere - - o VM storage type: snapshot/independent persistent/independent non- - persistent - - o Number of VMs - - o Number of Virtual NICs (vNICs), versions, type and driver - - o Number of virtual CPUs and their core affinity on the host - - o Number vNIC interrupt configuration - - o Thread affinitization for the applications (including the vSwitch - itself) on the host - - o Details of Resource isolation, such as CPUs designated for Host/ - Kernel (isolcpu) and CPUs designated for specific processes - (taskset). - Test duration. - Number of flows. - - Test Traffic Information: - - o Traffic type - UDP, TCP, IMIX / Other - - o Packet Sizes - - o Deployment Scenario - -3.4. Flow classification - - Virtual switches group packets into flows by processing and matching - particular packet or frame header information, or by matching packets - based on the input ports. Thus a flow can be thought of a sequence - of packets that have the same set of header field values (5-tuple) or - have arrived on the same port. Performance results can vary based on - the parameters the vSwitch uses to match for a flow. The recommended - flow classification parameters for any vSwitch performance tests are: - the input port, the source IP address, the destination IP address and - the Ethernet protocol type field. It is essential to increase the - flow timeout time on a vSwitch before conducting any performance - tests that do not measure the flow setup time. Normally the first - packet of a particular stream will install the flow in the virtual - switch which adds an additional latency, subsequent packets of the - same flow are not subject to this latency if the flow is already - installed on the vSwitch. - - - - -Tahhan, et al. Expires January 9, 2017 [Page 6] - -Internet-Draft Benchmarking vSwitches July 2016 - - -3.5. Benchmarks using Baselines with Resource Isolation - - This outline describes measurement of baseline with isolated - resources at a high level, which is the intended approach at this - time. - - 1. Baselines: - - * Optional: Benchmark platform forwarding capability without a - vswitch or VNF for at least 72 hours (serves as a means of - platform validation and a means to obtain the base performance - for the platform in terms of its maximum forwarding rate and - latency). - - Benchmark platform forwarding capability - - __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | Simple Forwarding App | | Host - | | | | | - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - * Benchmark VNF forwarding capability with direct connectivity - (vSwitch bypass, e.g., SR/IOV) for at least 72 hours (serves - as a means of VNF validation and a means to obtain the base - performance for the VNF in terms of its maximum forwarding - rate and latency). The metrics gathered from this test will - serve as a key comparison point for vSwitch bypass - technologies performance and vSwitch performance. - - - - - - - - - - -Tahhan, et al. Expires January 9, 2017 [Page 7] - -Internet-Draft Benchmarking vSwitches July 2016 - - - Benchmark VNF forwarding capability - - __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | VNF | | | - | | | | | - | +------------------------------------------+ | | - | | Passthrough/SR-IOV | | Host - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - * Benchmarking with isolated resources alone, with other - resources (both HW&SW) disabled Example, vSw and VM are SUT - - * Benchmarking with isolated resources alone, leaving some - resources unused - - * Benchmark with isolated resources and all resources occupied - - 2. Next Steps - - * Limited sharing - - * Production scenarios - - * Stressful scenarios - -4. VSWITCHPERF Specification Summary - - The overall specification in preparation is referred to as a Level - Test Design (LTD) document, which will contain a suite of performance - tests. The base performance tests in the LTD are based on the pre- - existing specifications developed by BMWG to test the performance of - physical switches. These specifications include: - - o [RFC2544] Benchmarking Methodology for Network Interconnect - Devices - - - -Tahhan, et al. Expires January 9, 2017 [Page 8] - -Internet-Draft Benchmarking vSwitches July 2016 - - - o [RFC2889] Benchmarking Methodology for LAN Switching - - o [RFC6201] Device Reset Characterization - - o [RFC5481] Packet Delay Variation Applicability Statement - - Some of the above/newer RFCs are being applied in benchmarking for - the first time, and represent a development challenge for test - equipment developers. Fortunately, many members of the testing - system community have engaged on the VSPERF project, including an - open source test system. - - In addition to this, the LTD also re-uses the terminology defined by: - - o [RFC2285] Benchmarking Terminology for LAN Switching Devices - - o [RFC5481] Packet Delay Variation Applicability Statement - - Specifications to be included in future updates of the LTD include: - - o [RFC3918] Methodology for IP Multicast Benchmarking - - o [RFC4737] Packet Reordering Metrics - - As one might expect, the most fundamental internetworking - characteristics of Throughput and Latency remain important when the - switch is virtualized, and these benchmarks figure prominently in the - specification. - - When considering characteristics important to "telco" network - functions, we must begin to consider additional performance metrics. - In this case, the project specifications have referenced metrics from - the IETF IP Performance Metrics (IPPM) literature. This means that - the [RFC2544] test of Latency is replaced by measurement of a metric - derived from IPPM's [RFC2679], where a set of statistical summaries - will be provided (mean, max, min, etc.). Further metrics planned to - be benchmarked include packet delay variation as defined by [RFC5481] - , reordering, burst behaviour, DUT availability, DUT capacity and - packet loss in long term testing at Throughput level, where some low- - level of background loss may be present and characterized. - - Tests have been (or will be) designed to collect the metrics below: - - o Throughput Tests to measure the maximum forwarding rate (in frames - per second or fps) and bit rate (in Mbps) for a constant load (as - defined by [RFC1242]) without traffic loss. - - - - - -Tahhan, et al. Expires January 9, 2017 [Page 9] - -Internet-Draft Benchmarking vSwitches July 2016 - - - o Packet and Frame Delay Distribution Tests to measure average, min - and max packet and frame delay for constant loads. - - o Packet Delay Tests to understand latency distribution for - different packet sizes and over an extended test run to uncover - outliers. - - o Scalability Tests to understand how the virtual switch performs as - the number of flows, active ports, complexity of the forwarding - logic's configuration... it has to deal with increases. - - o Stream Performance Tests (TCP, UDP) to measure bulk data transfer - performance, i.e. how fast systems can send and receive data - through the switch. - - o Control Path and Datapath Coupling Tests, to understand how - closely coupled the datapath and the control path are as well as - the effect of this coupling on the performance of the DUT - (example: delay of the initial packet of a flow). - - o CPU and Memory Consumption Tests to understand the virtual - switch's footprint on the system, usually conducted as auxiliary - measurements with benchmarks above. They include: CPU - utilization, Cache utilization and Memory footprint. - - o The so-called "Soak" tests, where the selected test is conducted - over a long period of time (with an ideal duration of 24 hours, - and at least 6 hours). The purpose of soak tests is to capture - transient changes in performance which may occur due to infrequent - processes or the low probability coincidence of two or more - processes. The performance must be evaluated periodically during - continuous testing, and this results in use of [RFC2889] Frame - Rate metrics instead of [RFC2544] Throughput (which requires - stopping traffic to allow time for all traffic to exit internal - queues). - - Future/planned test specs include: - - o Request/Response Performance Tests (TCP, UDP) which measure the - transaction rate through the switch. - - o Noisy Neighbour Tests, to understand the effects of resource - sharing on the performance of a virtual switch. - - o Tests derived from examination of ETSI NFV Draft GS IFA003 - requirements [IFA003] on characterization of acceleration - technologies applied to vswitches. - - - - -Tahhan, et al. Expires January 9, 2017 [Page 10] - -Internet-Draft Benchmarking vSwitches July 2016 - - - The flexibility of deployment of a virtual switch within a network - means that the BMWG IETF existing literature needs to be used to - characterize the performance of a switch in various deployment - scenarios. The deployment scenarios under consideration include: - - Physical port to virtual switch to physical port - - __ - +--------------------------------------------------+ | - | +--------------------+ | | - | | | | | - | | v | | Host - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires January 9, 2017 [Page 11] - -Internet-Draft Benchmarking vSwitches July 2016 - - - Physical port to virtual switch to VNF to virtual switch to physical - port - - __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ : | | - | | | | | Guest - | : v | | - | +---------------+ +---------------+ | | - | | logical port 0| | logical port 1| | | - +---+---------------+-----------+---------------+---+ __| - ^ : - | | - : v __ - +---+---------------+----------+---------------+---+ | - | | logical port 0| | logical port 1| | | - | +---------------+ +---------------+ | | - | ^ : | | - | | | | | Host - | : v | | - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - -Tahhan, et al. Expires January 9, 2017 [Page 12] - -Internet-Draft Benchmarking vSwitches July 2016 - - - Physical port to virtual switch to VNF to virtual switch to VNF to - virtual switch to physical port - - __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | ^ | | | ^ | | | - | | v | | | v | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 1 | | | | 0 1 | | | - +---+---------------+--+ +---+---------------+--+__| - ^ : ^ : - | | | | - : v : v _ - +---+---------------+---------+---------------+--+ | - | | 0 1 | | 3 4 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | ^ | ^ | | | Host - | | |-----------------| v | | - | +--------------+ +--------------+ | | - | | phy ports | vSwitch | phy ports | | | - +---+--------------+----------+--------------+---+_| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - -Tahhan, et al. Expires January 9, 2017 [Page 13] - -Internet-Draft Benchmarking vSwitches July 2016 - - - Physical port to virtual switch to VNF - - __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ | | - | | | | Guest - | : | | - | +---------------+ | | - | | logical port 0| | | - +---+---------------+-------------------------------+ __| - ^ - | - : __ - +---+---------------+------------------------------+ | - | | logical port 0| | | - | +---------------+ | | - | ^ | | - | | | | Host - | : | | - | +--------------+ | | - | | phy port | vSwitch | | - +---+--------------+------------ -------------- ---+ __| - ^ - | - : - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires January 9, 2017 [Page 14] - -Internet-Draft Benchmarking vSwitches July 2016 - - - VNF to virtual switch to physical port - - __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | : | | - | | | | Guest - | v | | - | +---------------+ | | - | | logical port | | | - +-------------------------------+---------------+---+ __| - : - | - v __ - +------------------------------+---------------+---+ | - | | logical port | | | - | +---------------+ | | - | : | | - | | | | Host - | v | | - | +--------------+ | | - | vSwitch | phy port | | | - +-------------------------------+--------------+---+ __| - : - | - v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires January 9, 2017 [Page 15] - -Internet-Draft Benchmarking vSwitches July 2016 - - - VNF to virtual switch to VNF - - __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | | | | ^ | | - | v | | | | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 | | | | 0 | | | - +---+---------------+--+ +---+---------------+--+__| - : ^ - | | - v : _ - +---+---------------+---------+---------------+--+ | - | | 1 | | 1 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | | ^ | | Host - | L-----------------+ | | - | | | - | vSwitch | | - +------------------------------------------------+_| - - A set of Deployment Scenario figures is available on the VSPERF Test - Methodology Wiki page [TestTopo]. - -5. 3x3 Matrix Coverage - - This section organizes the many existing test specifications into the - "3x3" matrix (introduced in [I-D.ietf-bmwg-virtual-net]). Because - the LTD specification ID names are quite long, this section is - organized into lists for each occupied cell of the matrix (not all - are occupied, also the matrix has grown to 3x4 to accommodate scale - metrics when displaying the coverage of many metrics/benchmarks). - The current version of the LTD specification is available [LTD]. - - The tests listed below assess the activation of paths in the data - plane, rather than the control plane. - - A complete list of tests with short summaries is available on the - VSPERF "LTD Test Spec Overview" Wiki page [LTDoverV]. - - - - - - -Tahhan, et al. Expires January 9, 2017 [Page 16] - -Internet-Draft Benchmarking vSwitches July 2016 - - -5.1. Speed of Activation - - o Activation.RFC2889.AddressLearningRate - - o PacketLatency.InitialPacketProcessingLatency - -5.2. Accuracy of Activation section - - o CPDP.Coupling.Flow.Addition - -5.3. Reliability of Activation - - o Throughput.RFC2544.SystemRecoveryTime - - o Throughput.RFC2544.ResetTime - -5.4. Scale of Activation - - o Activation.RFC2889.AddressCachingCapacity - -5.5. Speed of Operation - - o Throughput.RFC2544.PacketLossRate - - o CPU.RFC2544.0PacketLoss - - o Throughput.RFC2544.PacketLossRateFrameModification - - o Throughput.RFC2544.BackToBackFrames - - o Throughput.RFC2889.MaxForwardingRate - - o Throughput.RFC2889.ForwardPressure - - o Throughput.RFC2889.BroadcastFrameForwarding - -5.6. Accuracy of Operation - - o Throughput.RFC2889.ErrorFramesFiltering - - o Throughput.RFC2544.Profile - -5.7. Reliability of Operation - - o Throughput.RFC2889.Soak - - o Throughput.RFC2889.SoakFrameModification - - - - -Tahhan, et al. Expires January 9, 2017 [Page 17] - -Internet-Draft Benchmarking vSwitches July 2016 - - - o PacketDelayVariation.RFC3393.Soak - -5.8. Scalability of Operation - - o Scalability.RFC2544.0PacketLoss - - o MemoryBandwidth.RFC2544.0PacketLoss.Scalability - -5.9. Summary - -|------------------------------------------------------------------------| -| | | | | | -| | SPEED | ACCURACY | RELIABILITY | SCALE | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Activation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Operation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| De-activation | | | | | -| | | | | | -|------------------------------------------------------------------------| - -6. Security Considerations - - Benchmarking activities as described in this memo are limited to - technology characterization of a Device Under Test/System Under Test - (DUT/SUT) using controlled stimuli in a laboratory environment, with - dedicated address space and the constraints specified in the sections - above. - - The benchmarking network topology will be an independent test setup - and MUST NOT be connected to devices that may forward the test - traffic into a production network, or misroute traffic to the test - management network. - - Further, benchmarking is performed on a "black-box" basis, relying - solely on measurements observable external to the DUT/SUT. - - Special capabilities SHOULD NOT exist in the DUT/SUT specifically for - benchmarking purposes. Any implications for network security arising - from the DUT/SUT SHOULD be identical in the lab and in production - networks. - - - -Tahhan, et al. Expires January 9, 2017 [Page 18] - -Internet-Draft Benchmarking vSwitches July 2016 - - -7. IANA Considerations - - No IANA Action is requested at this time. - -8. Acknowledgements - - The authors appreciate and acknowledge comments from Scott Bradner, - Marius Georgescu, Ramki Krishnan, Doug Montgomery, Martin Klozik, - Christian Trautman, and others for their reviews. - -9. References - -9.1. Normative References - - [NFV.PER001] - "Network Function Virtualization: Performance and - Portability Best Practices", Group Specification ETSI GS - NFV-PER 001 V1.1.1 (2014-06), June 2014. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - <http://www.rfc-editor.org/info/rfc2119>. - - [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN - Switching Devices", RFC 2285, DOI 10.17487/RFC2285, - February 1998, <http://www.rfc-editor.org/info/rfc2285>. - - [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, - "Framework for IP Performance Metrics", RFC 2330, - DOI 10.17487/RFC2330, May 1998, - <http://www.rfc-editor.org/info/rfc2330>. - - [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for - Network Interconnect Devices", RFC 2544, - DOI 10.17487/RFC2544, March 1999, - <http://www.rfc-editor.org/info/rfc2544>. - - [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way - Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, - September 1999, <http://www.rfc-editor.org/info/rfc2679>. - - [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way - Packet Loss Metric for IPPM", RFC 2680, - DOI 10.17487/RFC2680, September 1999, - <http://www.rfc-editor.org/info/rfc2680>. - - - - - -Tahhan, et al. Expires January 9, 2017 [Page 19] - -Internet-Draft Benchmarking vSwitches July 2016 - - - [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip - Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, - September 1999, <http://www.rfc-editor.org/info/rfc2681>. - - [RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology - for LAN Switching Devices", RFC 2889, - DOI 10.17487/RFC2889, August 2000, - <http://www.rfc-editor.org/info/rfc2889>. - - [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation - Metric for IP Performance Metrics (IPPM)", RFC 3393, - DOI 10.17487/RFC3393, November 2002, - <http://www.rfc-editor.org/info/rfc3393>. - - [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network - performance measurement with periodic streams", RFC 3432, - DOI 10.17487/RFC3432, November 2002, - <http://www.rfc-editor.org/info/rfc3432>. - - [RFC3918] Stopp, D. and B. Hickman, "Methodology for IP Multicast - Benchmarking", RFC 3918, DOI 10.17487/RFC3918, October - 2004, <http://www.rfc-editor.org/info/rfc3918>. - - [RFC4689] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, - "Terminology for Benchmarking Network-layer Traffic - Control Mechanisms", RFC 4689, DOI 10.17487/RFC4689, - October 2006, <http://www.rfc-editor.org/info/rfc4689>. - - [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, - S., and J. Perser, "Packet Reordering Metrics", RFC 4737, - DOI 10.17487/RFC4737, November 2006, - <http://www.rfc-editor.org/info/rfc4737>. - - [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. - Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", - RFC 5357, DOI 10.17487/RFC5357, October 2008, - <http://www.rfc-editor.org/info/rfc5357>. - - [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, - "Network Time Protocol Version 4: Protocol and Algorithms - Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, - <http://www.rfc-editor.org/info/rfc5905>. - - [RFC6201] Asati, R., Pignataro, C., Calabria, F., and C. Olvera, - "Device Reset Characterization", RFC 6201, - DOI 10.17487/RFC6201, March 2011, - <http://www.rfc-editor.org/info/rfc6201>. - - - - -Tahhan, et al. Expires January 9, 2017 [Page 20] - -Internet-Draft Benchmarking vSwitches July 2016 - - -9.2. Informative References - - [BrahRel] "Brahmaputra, Second OPNFV Release https://www.opnfv.org/ - brahmaputra". - - [I-D.huang-bmwg-virtual-network-performance] - Huang, L., Rong, G., Mandeville, B., and B. Hickman, - "Benchmarking Methodology for Virtualization Network - Performance", draft-huang-bmwg-virtual-network- - performance-01 (work in progress), April 2015. - - [I-D.ietf-bmwg-virtual-net] - Morton, A., "Considerations for Benchmarking Virtual - Network Functions and Their Infrastructure", draft-ietf- - bmwg-virtual-net-03 (work in progress), June 2016. - - [IFA003] "https://docbox.etsi.org/ISG/NFV/Open/Drafts/ - IFA003_Acceleration_-_vSwitch_Spec/". - - [LTD] "LTD Test Specification - http://artifacts.opnfv.org/vswitchperf/docs/requirements/ - index.html". - - [LTDoverV] - "LTD Test Spec Overview https://wiki.opnfv.org/wiki/ - vswitchperf_test_spec_review". - - [RFC1242] Bradner, S., "Benchmarking Terminology for Network - Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, - July 1991, <http://www.rfc-editor.org/info/rfc1242>. - - [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation - Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, - March 2009, <http://www.rfc-editor.org/info/rfc5481>. - - [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of - Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, - <http://www.rfc-editor.org/info/rfc6049>. - - [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics - (IPPM) Registry of Metrics Are Obsolete", RFC 6248, - DOI 10.17487/RFC6248, April 2011, - <http://www.rfc-editor.org/info/rfc6248>. - - [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New - Performance Metric Development", BCP 170, RFC 6390, - DOI 10.17487/RFC6390, October 2011, - <http://www.rfc-editor.org/info/rfc6390>. - - - -Tahhan, et al. Expires January 9, 2017 [Page 21] - -Internet-Draft Benchmarking vSwitches July 2016 - - - [TestTopo] - "Test Topologies https://wiki.opnfv.org/vsperf/ - test_methodology". - -Authors' Addresses - - Maryam Tahhan - Intel - - Email: maryam.tahhan@intel.com - - - Billy O'Mahony - Intel - - Email: billy.o.mahony@intel.com - - - Al Morton - AT&T Labs - 200 Laurel Avenue South - Middletown,, NJ 07748 - USA - - Phone: +1 732 420 1571 - Fax: +1 732 368 1192 - Email: acmorton@att.com - URI: http://home.comcast.net/~acmacm/ - - - - - - - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires January 9, 2017 [Page 22] diff --git a/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.txt b/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.txt deleted file mode 100755 index b282bbb6..00000000 --- a/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-01.txt +++ /dev/null @@ -1,1232 +0,0 @@ - - - - -Network Working Group M. Tahhan -Internet-Draft B. O'Mahony -Intended status: Informational Intel -Expires: April 16, 2016 A. Morton - AT&T Labs - October 14, 2015 - - - Benchmarking Virtual Switches in OPNFV - draft-vsperf-bmwg-vswitch-opnfv-01 - -Abstract - - This memo describes the progress of the Open Platform for NFV (OPNFV) - project on virtual switch performance "VSWITCHPERF". This project - intends to build on the current and completed work of the - Benchmarking Methodology Working Group in IETF, by referencing - existing literature. The Benchmarking Methodology Working Group has - traditionally conducted laboratory characterization of dedicated - physical implementations of internetworking functions. Therefore, - this memo begins to describe the additional considerations when - virtual switches are implemented in general-purpose hardware. The - expanded tests and benchmarks are also influenced by the OPNFV - mission to support virtualization of the "telco" infrastructure. - -Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on April 16, 2016. - - - - -Tahhan, et al. Expires April 16, 2016 [Page 1] - -Internet-Draft Benchmarking vSwitches October 2015 - - -Copyright Notice - - Copyright (c) 2015 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Benchmarking Considerations . . . . . . . . . . . . . . . . . 4 - 3.1. Comparison with Physical Network Functions . . . . . . . 4 - 3.2. Continued Emphasis on Black-Box Benchmarks . . . . . . . 4 - 3.3. New Configuration Parameters . . . . . . . . . . . . . . 4 - 3.4. Flow classification . . . . . . . . . . . . . . . . . . . 6 - 3.5. Benchmarks using Baselines with Resource Isolation . . . 7 - 4. VSWITCHPERF Specification Summary . . . . . . . . . . . . . . 8 - 5. 3x3 Matrix Coverage . . . . . . . . . . . . . . . . . . . . . 16 - 5.1. Speed of Activation . . . . . . . . . . . . . . . . . . . 17 - 5.2. Accuracy of Activation section . . . . . . . . . . . . . 17 - 5.3. Reliability of Activation . . . . . . . . . . . . . . . . 17 - 5.4. Scale of Activation . . . . . . . . . . . . . . . . . . . 17 - 5.5. Speed of Operation . . . . . . . . . . . . . . . . . . . 17 - 5.6. Accuracy of Operation . . . . . . . . . . . . . . . . . . 17 - 5.7. Reliability of Operation . . . . . . . . . . . . . . . . 17 - 5.8. Scalability of Operation . . . . . . . . . . . . . . . . 18 - 5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 9.2. Informative References . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 - - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 2] - -Internet-Draft Benchmarking vSwitches October 2015 - - -1. Introduction - - Benchmarking Methodology Working Group (BMWG) has traditionally - conducted laboratory characterization of dedicated physical - implementations of internetworking functions. The Black-box - Benchmarks of Throughput, Latency, Forwarding Rates and others have - served our industry for many years. Now, Network Function - Virtualization (NFV) has the goal to transform how internetwork - functions are implemented, and therefore has garnered much attention. - - This memo describes the progress of the Open Platform for NFV (OPNFV) - project on virtual switch performance characterization, - "VSWITCHPERF". This project intends to build on the current and - completed work of the Benchmarking Methodology Working Group in IETF, - by referencing existing literature. For example, currently the most - often referenced RFC is [RFC2544] (which depends on [RFC1242]) and - foundation of the benchmarking work in OPNFV is common and strong. - - See https://wiki.opnfv.org/ - characterize_vswitch_performance_for_telco_nfv_use_cases for more - background, and the OPNFV website for general information: - https://www.opnfv.org/ - - The authors note that OPNFV distinguishes itself from other open - source compute and networking projects through its emphasis on - existing "telco" services as opposed to cloud-computing. There are - many ways in which telco requirements have different emphasis on - performance dimensions when compared to cloud computing: support for - and transfer of isochronous media streams is one example. - - Note also that the move to NFV Infrastructure has resulted in many - new benchmarking initiatives across the industry, and the authors are - currently doing their best to maintain alignment with many other - projects, and this Internet Draft is evidence of the efforts. - -2. Scope - - The primary purpose and scope of the memo is to inform BMWG of work- - in-progress that builds on the body of extensive literature and - experience. Additionally, once the initial information conveyed here - is received, this memo may be expanded to include more detail and - commentary from both BMWG and OPNFV communities, under BMWG's - chartered work to characterize the NFV Infrastructure (a virtual - switch is an important aspect of that infrastructure). - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 3] - -Internet-Draft Benchmarking vSwitches October 2015 - - -3. Benchmarking Considerations - - This section highlights some specific considerations (from - [I-D.ietf-bmwg-virtual-net])related to Benchmarks for virtual - switches. The OPNFV project is sharing its present view on these - areas, as they develop their specifications in the Level Test Design - (LTD) document. - -3.1. Comparison with Physical Network Functions - - To compare the performance of virtual designs and implementations - with their physical counterparts, identical benchmarks are needed. - BMWG has developed specifications for many network functions this - memo re-uses existing benchmarks through references, and expands them - during development of new methods. A key configuration aspect is the - number of parallel cores required to achieve comparable performance - with a given physical device, or whether some limit of scale was - reached before the cores could achieve the comparable level. - - It's unlikely that the virtual switch will be the only application - running on the SUT, so CPU utilization, Cache utilization, and Memory - footprint should also be recorded for the virtual implementations of - internetworking functions. - -3.2. Continued Emphasis on Black-Box Benchmarks - - External observations remain essential as the basis for Benchmarks. - Internal observations with fixed specification and interpretation - will be provided in parallel to assist the development of operations - procedures when the technology is deployed. - -3.3. New Configuration Parameters - - A key consideration when conducting any sort of benchmark is trying - to ensure the consistency and repeatability of test results. When - benchmarking the performance of a vSwitch there are many factors that - can affect the consistency of results, one key factor is matching the - various hardware and software details of the SUT. This section lists - some of the many new parameters which this project believes are - critical to report in order to achieve repeatability. - - Hardware details including: - - o Platform details - - o Processor details - - o Memory information (type and size) - - - -Tahhan, et al. Expires April 16, 2016 [Page 4] - -Internet-Draft Benchmarking vSwitches October 2015 - - - o Number of enabled cores - - o Number of cores used for the test - - o Number of physical NICs, as well as their details (manufacturer, - versions, type and the PCI slot they are plugged into) - - o NIC interrupt configuration - - o BIOS version, release date and any configurations that were - modified - - o CPU microcode level - - o Memory DIMM configurations (quad rank performance may not be the - same as dual rank) in size, freq and slot locations - - o PCI configuration parameters (payload size, early ack option...) - - o Power management at all levels (ACPI sleep states, processor - package, OS...) - - Software details including: - - o OS parameters and behavior (text vs graphical no one typing at the - console on one system) - - o OS version (for host and VNF) - - o Kernel version (for host and VNF) - - o GRUB boot parameters (for host and VNF) - - o Hypervisor details (Type and version) - - o Selected vSwitch, version number or commit id used - - o vSwitch launch command line if it has been parameterised - - o Memory allocation to the vSwitch - - o which NUMA node it is using, and how many memory channels - - o DPDK or any other SW dependency version number or commit id used - - o Memory allocation to a VM - if it's from Hugpages/elsewhere - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 5] - -Internet-Draft Benchmarking vSwitches October 2015 - - - o VM storage type: snapshot/independent persistent/independent non- - persistent - - o Number of VMs - - o Number of Virtual NICs (vNICs), versions, type and driver - - o Number of virtual CPUs and their core affinity on the host - - o Number vNIC interrupt configuration - - o Thread affinitization for the applications (including the vSwitch - itself) on the host - - o Details of Resource isolation, such as CPUs designated for Host/ - Kernel (isolcpu) and CPUs designated for specific processes - (taskset). - Test duration. - Number of flows. - - Test Traffic Information: - - o Traffic type - UDP, TCP, IMIX / Other - - o Packet Sizes - - o Deployment Scenario - -3.4. Flow classification - - Virtual switches group packets into flows by processing and matching - particular packet or frame header information, or by matching packets - based on the input ports. Thus a flow can be thought of a sequence - of packets that have the same set of header field values or have - arrived on the same port. Performance results can vary based on the - parameters the vSwitch uses to match for a flow. The recommended - flow classification parameters for any vSwitch performance tests are: - the input port, the source IP address, the destination IP address and - the Ethernet protocol type field. It is essential to increase the - flow timeout time on a vSwitch before conducting any performance - tests that do not measure the flow setup time. Normally the first - packet of a particular stream will install the flow in the virtual - switch which adds an additional latency, subsequent packets of the - same flow are not subject to this latency if the flow is already - installed on the vSwitch. - - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 6] - -Internet-Draft Benchmarking vSwitches October 2015 - - -3.5. Benchmarks using Baselines with Resource Isolation - - This outline describes measurement of baseline with isolated - resources at a high level, which is the intended approach at this - time. - - 1. Baselines: - - * Optional: Benchmark platform forwarding capability without a - vswitch or VNF for at least 72 hours (serves as a means of - platform validation and a means to obtain the base performance - for the platform in terms of its maximum forwarding rate and - latency). - - Benchmark platform forwarding capability - - __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | Simple Forwarding App | | Host - | | | | | - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - * Benchmark VNF forwarding capability with direct connectivity - (vSwitch bypass, e.g., SR/IOV) for at least 72 hours (serves - as a means of VNF validation and a means to obtain the base - performance for the VNF in terms of its maximum forwarding - rate and latency). The metrics gathered from this test will - serve as a key comparison point for vSwitch bypass - technologies performance and vSwitch performance. - - - - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 7] - -Internet-Draft Benchmarking vSwitches October 2015 - - - Benchmark VNF forwarding capability - - __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | VNF | | | - | | | | | - | +------------------------------------------+ | | - | | Passthrough/SR-IOV | | Host - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - * Benchmarking with isolated resources alone, with other - resources (both HW&SW) disabled Example, vSw and VM are SUT - - * Benchmarking with isolated resources alone, leaving some - resources unused - - * Benchmark with isolated resources and all resources occupied - - 2. Next Steps - - * Limited sharing - - * Production scenarios - - * Stressful scenarios - -4. VSWITCHPERF Specification Summary - - The overall specification in preparation is referred to as a Level - Test Design (LTD) document, which will contain a suite of performance - tests. The base performance tests in the LTD are based on the pre- - existing specifications developed by BMWG to test the performance of - physical switches. These specifications include: - - o [RFC2544] Benchmarking Methodology for Network Interconnect - Devices - - - -Tahhan, et al. Expires April 16, 2016 [Page 8] - -Internet-Draft Benchmarking vSwitches October 2015 - - - o [RFC2889] Benchmarking Methodology for LAN Switching - - o [RFC6201] Device Reset Characterization - - o [RFC5481] Packet Delay Variation Applicability Statement - - Some of the above/newer RFCs are being applied in benchmarking for - the first time, and represent a development challenge for test - equipment developers. Fortunately, many members of the testing - system community have engaged on the VSPERF project, including an - open source test system. - - In addition to this, the LTD also re-uses the terminology defined by: - - o [RFC2285] Benchmarking Terminology for LAN Switching Devices - - o [RFC5481] Packet Delay Variation Applicability Statement - - Specifications to be included in future updates of the LTD include: - - o [RFC3918] Methodology for IP Multicast Benchmarking - - o [RFC4737] Packet Reordering Metrics - - As one might expect, the most fundamental internetworking - characteristics of Throughput and Latency remain important when the - switch is virtualized, and these benchmarks figure prominently in the - specification. - - When considering characteristics important to "telco" network - functions, we must begin to consider additional performance metrics. - In this case, the project specifications have referenced metrics from - the IETF IP Performance Metrics (IPPM) literature. This means that - the [RFC2544] test of Latency is replaced by measurement of a metric - derived from IPPM's [RFC2679], where a set of statistical summaries - will be provided (mean, max, min, etc.). Further metrics planned to - be benchmarked include packet delay variation as defined by [RFC5481] - , reordering, burst behaviour, DUT availability, DUT capacity and - packet loss in long term testing at Throughput level, where some low- - level of background loss may be present and characterized. - - Tests have been (or will be) designed to collect the metrics below: - - o Throughput Tests to measure the maximum forwarding rate (in frames - per second or fps) and bit rate (in Mbps) for a constant load (as - defined by RFC1242) without traffic loss. - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 9] - -Internet-Draft Benchmarking vSwitches October 2015 - - - o Packet and Frame Delay Distribution Tests to measure average, min - and max packet and frame delay for constant loads. - - o Packet Delay Tests to understand latency distribution for - different packet sizes and over an extended test run to uncover - outliers. - - o Scalability Tests to understand how the virtual switch performs as - the number of flows, active ports, complexity of the forwarding - logic's configuration... it has to deal with increases. - - o Stream Performance Tests (TCP, UDP) to measure bulk data transfer - performance, i.e. how fast systems can send and receive data - through the switch. - - o Control Path and Datapath Coupling Tests, to understand how - closely coupled the datapath and the control path are as well as - the effect of this coupling on the performance of the DUT - (example: delay of the initial packet of a flow). - - o CPU and Memory Consumption Tests to understand the virtual - switch's footprint on the system, usually conducted as auxiliary - measurements with benchmarks above. They include: CPU - utilization, Cache utilization and Memory footprint. - - Future/planned test specs include: - - o Request/Response Performance Tests (TCP, UDP) which measure the - transaction rate through the switch. - - o Noisy Neighbour Tests, to understand the effects of resource - sharing on the performance of a virtual switch. - - o Tests derived from examination of ETSI NFV Draft GS IFA003 - requirements [IFA003] on characterization of acceleration - technologies applied to vswitches. - - The flexibility of deployment of a virtual switch within a network - means that the BMWG IETF existing literature needs to be used to - characterize the performance of a switch in various deployment - scenarios. The deployment scenarios under consideration include: - - - - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 10] - -Internet-Draft Benchmarking vSwitches October 2015 - - - Physical port to virtual switch to physical port - - __ - +--------------------------------------------------+ | - | +--------------------+ | | - | | | | | - | | v | | Host - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 11] - -Internet-Draft Benchmarking vSwitches October 2015 - - - Physical port to virtual switch to VNF to virtual switch to physical - port - - __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ : | | - | | | | | Guest - | : v | | - | +---------------+ +---------------+ | | - | | logical port 0| | logical port 1| | | - +---+---------------+-----------+---------------+---+ __| - ^ : - | | - : v __ - +---+---------------+----------+---------------+---+ | - | | logical port 0| | logical port 1| | | - | +---------------+ +---------------+ | | - | ^ : | | - | | | | | Host - | : v | | - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 12] - -Internet-Draft Benchmarking vSwitches October 2015 - - - Physical port to virtual switch to VNF to virtual switch to VNF to - virtual switch to physical port - - __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | ^ | | | ^ | | | - | | v | | | v | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 1 | | | | 0 1 | | | - +---+---------------+--+ +---+---------------+--+__| - ^ : ^ : - | | | | - : v : v _ - +---+---------------+---------+---------------+--+ | - | | 0 1 | | 3 4 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | ^ | ^ | | | Host - | | |-----------------| v | | - | +--------------+ +--------------+ | | - | | phy ports | vSwitch | phy ports | | | - +---+--------------+----------+--------------+---+_| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 13] - -Internet-Draft Benchmarking vSwitches October 2015 - - - Physical port to virtual switch to VNF - - __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ | | - | | | | Guest - | : | | - | +---------------+ | | - | | logical port 0| | | - +---+---------------+-------------------------------+ __| - ^ - | - : __ - +---+---------------+------------------------------+ | - | | logical port 0| | | - | +---------------+ | | - | ^ | | - | | | | Host - | : | | - | +--------------+ | | - | | phy port | vSwitch | | - +---+--------------+------------ -------------- ---+ __| - ^ - | - : - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 14] - -Internet-Draft Benchmarking vSwitches October 2015 - - - VNF to virtual switch to physical port - - __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | : | | - | | | | Guest - | v | | - | +---------------+ | | - | | logical port | | | - +-------------------------------+---------------+---+ __| - : - | - v __ - +------------------------------+---------------+---+ | - | | logical port | | | - | +---------------+ | | - | : | | - | | | | Host - | v | | - | +--------------+ | | - | vSwitch | phy port | | | - +-------------------------------+--------------+---+ __| - : - | - v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 15] - -Internet-Draft Benchmarking vSwitches October 2015 - - - VNF to virtual switch to VNF - - __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | | | | ^ | | - | v | | | | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 | | | | 0 | | | - +---+---------------+--+ +---+---------------+--+__| - : ^ - | | - v : _ - +---+---------------+---------+---------------+--+ | - | | 1 | | 1 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | | ^ | | Host - | L-----------------+ | | - | | | - | vSwitch | | - +------------------------------------------------+_| - - A set of Deployment Scenario figures is available on the VSPERF Test - Methodology Wiki page [TestTopo]. - -5. 3x3 Matrix Coverage - - This section organizes the many existing test specifications into the - "3x3" matrix (introduced in [I-D.ietf-bmwg-virtual-net]). Because - the LTD specification ID names are quite long, this section is - organized into lists for each occupied cell of the matrix (not all - are occupied, also the matrix has grown to 3x4 to accommodate scale - metrics when displaying the coverage of many metrics/benchmarks). - - The tests listed below assess the activation of paths in the data - plane, rather than the control plane. - - A complete list of tests with short summaries is available on the - VSPERF "LTD Test Spec Overview" Wiki page [LTDoverV]. - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 16] - -Internet-Draft Benchmarking vSwitches October 2015 - - -5.1. Speed of Activation - - o Activation.RFC2889.AddressLearningRate - - o PacketLatency.InitialPacketProcessingLatency - -5.2. Accuracy of Activation section - - o CPDP.Coupling.Flow.Addition - -5.3. Reliability of Activation - - o Throughput.RFC2544.SystemRecoveryTime - - o Throughput.RFC2544.ResetTime - -5.4. Scale of Activation - - o Activation.RFC2889.AddressCachingCapacity - -5.5. Speed of Operation - - o Throughput.RFC2544.PacketLossRate - - o CPU.RFC2544.0PacketLoss - - o Throughput.RFC2544.PacketLossRateFrameModification - - o Throughput.RFC2544.BackToBackFrames - - o Throughput.RFC2889.MaxForwardingRate - - o Throughput.RFC2889.ForwardPressure - - o Throughput.RFC2889.BroadcastFrameForwarding - -5.6. Accuracy of Operation - - o Throughput.RFC2889.ErrorFramesFiltering - - o Throughput.RFC2544.Profile - -5.7. Reliability of Operation - - o Throughput.RFC2889.Soak - - o Throughput.RFC2889.SoakFrameModification - - - - -Tahhan, et al. Expires April 16, 2016 [Page 17] - -Internet-Draft Benchmarking vSwitches October 2015 - - - o PacketDelayVariation.RFC3393.Soak - -5.8. Scalability of Operation - - o Scalability.RFC2544.0PacketLoss - - o MemoryBandwidth.RFC2544.0PacketLoss.Scalability - -5.9. Summary - -|------------------------------------------------------------------------| -| | | | | | -| | SPEED | ACCURACY | RELIABILITY | SCALE | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Activation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Operation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| De-activation | | | | | -| | | | | | -|------------------------------------------------------------------------| - -6. Security Considerations - - Benchmarking activities as described in this memo are limited to - technology characterization of a Device Under Test/System Under Test - (DUT/SUT) using controlled stimuli in a laboratory environment, with - dedicated address space and the constraints specified in the sections - above. - - The benchmarking network topology will be an independent test setup - and MUST NOT be connected to devices that may forward the test - traffic into a production network, or misroute traffic to the test - management network. - - Further, benchmarking is performed on a "black-box" basis, relying - solely on measurements observable external to the DUT/SUT. - - Special capabilities SHOULD NOT exist in the DUT/SUT specifically for - benchmarking purposes. Any implications for network security arising - from the DUT/SUT SHOULD be identical in the lab and in production - networks. - - - -Tahhan, et al. Expires April 16, 2016 [Page 18] - -Internet-Draft Benchmarking vSwitches October 2015 - - -7. IANA Considerations - - No IANA Action is requested at this time. - -8. Acknowledgements - - The authors acknowledge - -9. References - -9.1. Normative References - - [NFV.PER001] - "Network Function Virtualization: Performance and - Portability Best Practices", Group Specification ETSI GS - NFV-PER 001 V1.1.1 (2014-06), June 2014. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - <http://www.rfc-editor.org/info/rfc2119>. - - [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN - Switching Devices", RFC 2285, DOI 10.17487/RFC2285, - February 1998, <http://www.rfc-editor.org/info/rfc2285>. - - [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, - "Framework for IP Performance Metrics", RFC 2330, - DOI 10.17487/RFC2330, May 1998, - <http://www.rfc-editor.org/info/rfc2330>. - - [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for - Network Interconnect Devices", RFC 2544, - DOI 10.17487/RFC2544, March 1999, - <http://www.rfc-editor.org/info/rfc2544>. - - [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way - Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, - September 1999, <http://www.rfc-editor.org/info/rfc2679>. - - [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way - Packet Loss Metric for IPPM", RFC 2680, - DOI 10.17487/RFC2680, September 1999, - <http://www.rfc-editor.org/info/rfc2680>. - - [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip - Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, - September 1999, <http://www.rfc-editor.org/info/rfc2681>. - - - -Tahhan, et al. Expires April 16, 2016 [Page 19] - -Internet-Draft Benchmarking vSwitches October 2015 - - - [RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology - for LAN Switching Devices", RFC 2889, - DOI 10.17487/RFC2889, August 2000, - <http://www.rfc-editor.org/info/rfc2889>. - - [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation - Metric for IP Performance Metrics (IPPM)", RFC 3393, - DOI 10.17487/RFC3393, November 2002, - <http://www.rfc-editor.org/info/rfc3393>. - - [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network - performance measurement with periodic streams", RFC 3432, - DOI 10.17487/RFC3432, November 2002, - <http://www.rfc-editor.org/info/rfc3432>. - - [RFC3918] Stopp, D. and B. Hickman, "Methodology for IP Multicast - Benchmarking", RFC 3918, DOI 10.17487/RFC3918, October - 2004, <http://www.rfc-editor.org/info/rfc3918>. - - [RFC4689] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, - "Terminology for Benchmarking Network-layer Traffic - Control Mechanisms", RFC 4689, DOI 10.17487/RFC4689, - October 2006, <http://www.rfc-editor.org/info/rfc4689>. - - [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, - S., and J. Perser, "Packet Reordering Metrics", RFC 4737, - DOI 10.17487/RFC4737, November 2006, - <http://www.rfc-editor.org/info/rfc4737>. - - [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. - Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", - RFC 5357, DOI 10.17487/RFC5357, October 2008, - <http://www.rfc-editor.org/info/rfc5357>. - - [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, - "Network Time Protocol Version 4: Protocol and Algorithms - Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, - <http://www.rfc-editor.org/info/rfc5905>. - - [RFC6201] Asati, R., Pignataro, C., Calabria, F., and C. Olvera, - "Device Reset Characterization", RFC 6201, - DOI 10.17487/RFC6201, March 2011, - <http://www.rfc-editor.org/info/rfc6201>. - - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 20] - -Internet-Draft Benchmarking vSwitches October 2015 - - -9.2. Informative References - - [I-D.ietf-bmwg-virtual-net] - Morton, A., "Considerations for Benchmarking Virtual - Network Functions and Their Infrastructure", draft-ietf- - bmwg-virtual-net-01 (work in progress), September 2015. - - [IFA003] "https://docbox.etsi.org/ISG/NFV/Open/Drafts/ - IFA003_Acceleration_-_vSwitch_Spec/". - - [LTDoverV] - "LTD Test Spec Overview https://wiki.opnfv.org/wiki/ - vswitchperf_test_spec_review". - - [RFC1242] Bradner, S., "Benchmarking Terminology for Network - Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, - July 1991, <http://www.rfc-editor.org/info/rfc1242>. - - [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation - Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, - March 2009, <http://www.rfc-editor.org/info/rfc5481>. - - [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of - Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, - <http://www.rfc-editor.org/info/rfc6049>. - - [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics - (IPPM) Registry of Metrics Are Obsolete", RFC 6248, - DOI 10.17487/RFC6248, April 2011, - <http://www.rfc-editor.org/info/rfc6248>. - - [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New - Performance Metric Development", BCP 170, RFC 6390, - DOI 10.17487/RFC6390, October 2011, - <http://www.rfc-editor.org/info/rfc6390>. - - [TestTopo] - "Test Topologies https://wiki.opnfv.org/vsperf/ - test_methodology". - -Authors' Addresses - - Maryam Tahhan - Intel - - Email: maryam.tahhan@intel.com - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 21] - -Internet-Draft Benchmarking vSwitches October 2015 - - - Billy O'Mahony - Intel - - Email: billy.o.mahony@intel.com - - - Al Morton - AT&T Labs - 200 Laurel Avenue South - Middletown,, NJ 07748 - USA - - Phone: +1 732 420 1571 - Fax: +1 732 368 1192 - Email: acmorton@att.com - URI: http://home.comcast.net/~acmacm/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires April 16, 2016 [Page 22] diff --git a/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-02.txt b/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-02.txt deleted file mode 100755 index 0f5be592..00000000 --- a/docs/requirements/ietf_draft/draft-vsperf-bmwg-vswitch-opnfv-02.txt +++ /dev/null @@ -1,1232 +0,0 @@ - - - - -Network Working Group M. Tahhan -Internet-Draft B. O'Mahony -Intended status: Informational Intel -Expires: September 22, 2016 A. Morton - AT&T Labs - March 21, 2016 - - - Benchmarking Virtual Switches in OPNFV - draft-vsperf-bmwg-vswitch-opnfv-02 - -Abstract - - This memo describes the progress of the Open Platform for NFV (OPNFV) - project on virtual switch performance "VSWITCHPERF". This project - intends to build on the current and completed work of the - Benchmarking Methodology Working Group in IETF, by referencing - existing literature. The Benchmarking Methodology Working Group has - traditionally conducted laboratory characterization of dedicated - physical implementations of internetworking functions. Therefore, - this memo begins to describe the additional considerations when - virtual switches are implemented in general-purpose hardware. The - expanded tests and benchmarks are also influenced by the OPNFV - mission to support virtualization of the "telco" infrastructure. - -Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on September 22, 2016. - - - - -Tahhan, et al. Expires September 22, 2016 [Page 1] - -Internet-Draft Benchmarking vSwitches March 2016 - - -Copyright Notice - - Copyright (c) 2016 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Benchmarking Considerations . . . . . . . . . . . . . . . . . 4 - 3.1. Comparison with Physical Network Functions . . . . . . . 4 - 3.2. Continued Emphasis on Black-Box Benchmarks . . . . . . . 4 - 3.3. New Configuration Parameters . . . . . . . . . . . . . . 4 - 3.4. Flow classification . . . . . . . . . . . . . . . . . . . 6 - 3.5. Benchmarks using Baselines with Resource Isolation . . . 7 - 4. VSWITCHPERF Specification Summary . . . . . . . . . . . . . . 8 - 5. 3x3 Matrix Coverage . . . . . . . . . . . . . . . . . . . . . 16 - 5.1. Speed of Activation . . . . . . . . . . . . . . . . . . . 17 - 5.2. Accuracy of Activation section . . . . . . . . . . . . . 17 - 5.3. Reliability of Activation . . . . . . . . . . . . . . . . 17 - 5.4. Scale of Activation . . . . . . . . . . . . . . . . . . . 17 - 5.5. Speed of Operation . . . . . . . . . . . . . . . . . . . 17 - 5.6. Accuracy of Operation . . . . . . . . . . . . . . . . . . 17 - 5.7. Reliability of Operation . . . . . . . . . . . . . . . . 17 - 5.8. Scalability of Operation . . . . . . . . . . . . . . . . 18 - 5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 9.2. Informative References . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 - - - - - - - - -Tahhan, et al. Expires September 22, 2016 [Page 2] - -Internet-Draft Benchmarking vSwitches March 2016 - - -1. Introduction - - Benchmarking Methodology Working Group (BMWG) has traditionally - conducted laboratory characterization of dedicated physical - implementations of internetworking functions. The Black-box - Benchmarks of Throughput, Latency, Forwarding Rates and others have - served our industry for many years. Now, Network Function - Virtualization (NFV) has the goal to transform how internetwork - functions are implemented, and therefore has garnered much attention. - - This memo summarizes the progress of the Open Platform for NFV - (OPNFV) project on virtual switch performance characterization, - "VSWITCHPERF", through the Brahmaputra (second) release [BrahRel]. - This project intends to build on the current and completed work of - the Benchmarking Methodology Working Group in IETF, by referencing - existing literature. For example, currently the most often - referenced RFC is [RFC2544] (which depends on [RFC1242]) and - foundation of the benchmarking work in OPNFV is common and strong. - - See https://wiki.opnfv.org/ - characterize_vswitch_performance_for_telco_nfv_use_cases for more - background, and the OPNFV website for general information: - https://www.opnfv.org/ - - The authors note that OPNFV distinguishes itself from other open - source compute and networking projects through its emphasis on - existing "telco" services as opposed to cloud-computing. There are - many ways in which telco requirements have different emphasis on - performance dimensions when compared to cloud computing: support for - and transfer of isochronous media streams is one example. - - Note also that the move to NFV Infrastructure has resulted in many - new benchmarking initiatives across the industry. The authors are - currently doing their best to maintain alignment with many other - projects, and this Internet Draft is one part of the efforts. We - acknowledge the early work in - [I-D.huang-bmwg-virtual-network-performance], and useful discussion - with the authors. - -2. Scope - - The primary purpose and scope of the memo is to inform the industry - of work-in-progress that builds on the body of extensive BMWG - literature and experience, and describe the extensions needed for - benchmarking virtual switches. Inital feedback indicates that many - of these extensions may be applicable beyond the current scope (to - hardware switches in the NFV Infrastructure and to virtual routers, - for example). Additionally, this memo serves as a vehicle to include - - - -Tahhan, et al. Expires September 22, 2016 [Page 3] - -Internet-Draft Benchmarking vSwitches March 2016 - - - more detail and commentary from BMWG and other Open Source - communities, under BMWG's chartered work to characterize the NFV - Infrastructure (a virtual switch is an important aspect of that - infrastructure). - -3. Benchmarking Considerations - - This section highlights some specific considerations (from - [I-D.ietf-bmwg-virtual-net])related to Benchmarks for virtual - switches. The OPNFV project is sharing its present view on these - areas, as they develop their specifications in the Level Test Design - (LTD) document. - -3.1. Comparison with Physical Network Functions - - To compare the performance of virtual designs and implementations - with their physical counterparts, identical benchmarks are needed. - BMWG has developed specifications for many network functions this - memo re-uses existing benchmarks through references, and expands them - during development of new methods. A key configuration aspect is the - number of parallel cores required to achieve comparable performance - with a given physical device, or whether some limit of scale was - reached before the cores could achieve the comparable level. - - It's unlikely that the virtual switch will be the only application - running on the SUT, so CPU utilization, Cache utilization, and Memory - footprint should also be recorded for the virtual implementations of - internetworking functions. - -3.2. Continued Emphasis on Black-Box Benchmarks - - External observations remain essential as the basis for Benchmarks. - Internal observations with fixed specification and interpretation - will be provided in parallel to assist the development of operations - procedures when the technology is deployed. - -3.3. New Configuration Parameters - - A key consideration when conducting any sort of benchmark is trying - to ensure the consistency and repeatability of test results. When - benchmarking the performance of a vSwitch there are many factors that - can affect the consistency of results, one key factor is matching the - various hardware and software details of the SUT. This section lists - some of the many new parameters which this project believes are - critical to report in order to achieve repeatability. - - Hardware details including: - - - - -Tahhan, et al. Expires September 22, 2016 [Page 4] - -Internet-Draft Benchmarking vSwitches March 2016 - - - o Platform details - - o Processor details - - o Memory information (type and size) - - o Number of enabled cores - - o Number of cores used for the test - - o Number of physical NICs, as well as their details (manufacturer, - versions, type and the PCI slot they are plugged into) - - o NIC interrupt configuration - - o BIOS version, release date and any configurations that were - modified - - o CPU microcode level - - o Memory DIMM configurations (quad rank performance may not be the - same as dual rank) in size, freq and slot locations - - o PCI configuration parameters (payload size, early ack option...) - - o Power management at all levels (ACPI sleep states, processor - package, OS...) - - Software details including: - - o OS parameters and behavior (text vs graphical no one typing at the - console on one system) - - o OS version (for host and VNF) - - o Kernel version (for host and VNF) - - o GRUB boot parameters (for host and VNF) - - o Hypervisor details (Type and version) - - o Selected vSwitch, version number or commit id used - - o vSwitch launch command line if it has been parameterised - - o Memory allocation to the vSwitch - - o which NUMA node it is using, and how many memory channels - - - -Tahhan, et al. Expires September 22, 2016 [Page 5] - -Internet-Draft Benchmarking vSwitches March 2016 - - - o DPDK or any other SW dependency version number or commit id used - - o Memory allocation to a VM - if it's from Hugpages/elsewhere - - o VM storage type: snapshot/independent persistent/independent non- - persistent - - o Number of VMs - - o Number of Virtual NICs (vNICs), versions, type and driver - - o Number of virtual CPUs and their core affinity on the host - - o Number vNIC interrupt configuration - - o Thread affinitization for the applications (including the vSwitch - itself) on the host - - o Details of Resource isolation, such as CPUs designated for Host/ - Kernel (isolcpu) and CPUs designated for specific processes - (taskset). - Test duration. - Number of flows. - - Test Traffic Information: - - o Traffic type - UDP, TCP, IMIX / Other - - o Packet Sizes - - o Deployment Scenario - -3.4. Flow classification - - Virtual switches group packets into flows by processing and matching - particular packet or frame header information, or by matching packets - based on the input ports. Thus a flow can be thought of a sequence - of packets that have the same set of header field values or have - arrived on the same port. Performance results can vary based on the - parameters the vSwitch uses to match for a flow. The recommended - flow classification parameters for any vSwitch performance tests are: - the input port, the source IP address, the destination IP address and - the Ethernet protocol type field. It is essential to increase the - flow timeout time on a vSwitch before conducting any performance - tests that do not measure the flow setup time. Normally the first - packet of a particular stream will install the flow in the virtual - switch which adds an additional latency, subsequent packets of the - same flow are not subject to this latency if the flow is already - installed on the vSwitch. - - - - -Tahhan, et al. Expires September 22, 2016 [Page 6] - -Internet-Draft Benchmarking vSwitches March 2016 - - -3.5. Benchmarks using Baselines with Resource Isolation - - This outline describes measurement of baseline with isolated - resources at a high level, which is the intended approach at this - time. - - 1. Baselines: - - * Optional: Benchmark platform forwarding capability without a - vswitch or VNF for at least 72 hours (serves as a means of - platform validation and a means to obtain the base performance - for the platform in terms of its maximum forwarding rate and - latency). - - Benchmark platform forwarding capability - - __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | Simple Forwarding App | | Host - | | | | | - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - * Benchmark VNF forwarding capability with direct connectivity - (vSwitch bypass, e.g., SR/IOV) for at least 72 hours (serves - as a means of VNF validation and a means to obtain the base - performance for the VNF in terms of its maximum forwarding - rate and latency). The metrics gathered from this test will - serve as a key comparison point for vSwitch bypass - technologies performance and vSwitch performance. - - - - - - - - - - -Tahhan, et al. Expires September 22, 2016 [Page 7] - -Internet-Draft Benchmarking vSwitches March 2016 - - - Benchmark VNF forwarding capability - - __ - +--------------------------------------------------+ | - | +------------------------------------------+ | | - | | | | | - | | VNF | | | - | | | | | - | +------------------------------------------+ | | - | | Passthrough/SR-IOV | | Host - | +------------------------------------------+ | | - | | NIC | | | - +---+------------------------------------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - * Benchmarking with isolated resources alone, with other - resources (both HW&SW) disabled Example, vSw and VM are SUT - - * Benchmarking with isolated resources alone, leaving some - resources unused - - * Benchmark with isolated resources and all resources occupied - - 2. Next Steps - - * Limited sharing - - * Production scenarios - - * Stressful scenarios - -4. VSWITCHPERF Specification Summary - - The overall specification in preparation is referred to as a Level - Test Design (LTD) document, which will contain a suite of performance - tests. The base performance tests in the LTD are based on the pre- - existing specifications developed by BMWG to test the performance of - physical switches. These specifications include: - - o [RFC2544] Benchmarking Methodology for Network Interconnect - Devices - - - -Tahhan, et al. Expires September 22, 2016 [Page 8] - -Internet-Draft Benchmarking vSwitches March 2016 - - - o [RFC2889] Benchmarking Methodology for LAN Switching - - o [RFC6201] Device Reset Characterization - - o [RFC5481] Packet Delay Variation Applicability Statement - - Some of the above/newer RFCs are being applied in benchmarking for - the first time, and represent a development challenge for test - equipment developers. Fortunately, many members of the testing - system community have engaged on the VSPERF project, including an - open source test system. - - In addition to this, the LTD also re-uses the terminology defined by: - - o [RFC2285] Benchmarking Terminology for LAN Switching Devices - - o [RFC5481] Packet Delay Variation Applicability Statement - - Specifications to be included in future updates of the LTD include: - - o [RFC3918] Methodology for IP Multicast Benchmarking - - o [RFC4737] Packet Reordering Metrics - - As one might expect, the most fundamental internetworking - characteristics of Throughput and Latency remain important when the - switch is virtualized, and these benchmarks figure prominently in the - specification. - - When considering characteristics important to "telco" network - functions, we must begin to consider additional performance metrics. - In this case, the project specifications have referenced metrics from - the IETF IP Performance Metrics (IPPM) literature. This means that - the [RFC2544] test of Latency is replaced by measurement of a metric - derived from IPPM's [RFC2679], where a set of statistical summaries - will be provided (mean, max, min, etc.). Further metrics planned to - be benchmarked include packet delay variation as defined by [RFC5481] - , reordering, burst behaviour, DUT availability, DUT capacity and - packet loss in long term testing at Throughput level, where some low- - level of background loss may be present and characterized. - - Tests have been (or will be) designed to collect the metrics below: - - o Throughput Tests to measure the maximum forwarding rate (in frames - per second or fps) and bit rate (in Mbps) for a constant load (as - defined by [RFC1242]) without traffic loss. - - - - - -Tahhan, et al. Expires September 22, 2016 [Page 9] - -Internet-Draft Benchmarking vSwitches March 2016 - - - o Packet and Frame Delay Distribution Tests to measure average, min - and max packet and frame delay for constant loads. - - o Packet Delay Tests to understand latency distribution for - different packet sizes and over an extended test run to uncover - outliers. - - o Scalability Tests to understand how the virtual switch performs as - the number of flows, active ports, complexity of the forwarding - logic's configuration... it has to deal with increases. - - o Stream Performance Tests (TCP, UDP) to measure bulk data transfer - performance, i.e. how fast systems can send and receive data - through the switch. - - o Control Path and Datapath Coupling Tests, to understand how - closely coupled the datapath and the control path are as well as - the effect of this coupling on the performance of the DUT - (example: delay of the initial packet of a flow). - - o CPU and Memory Consumption Tests to understand the virtual - switch's footprint on the system, usually conducted as auxiliary - measurements with benchmarks above. They include: CPU - utilization, Cache utilization and Memory footprint. - - o The so-called "Soak" tests, where the selected test is conducted - over a long period of time (with an ideal duration of 24 hours, - and at least 6 hours). The purpose of soak tests is to capture - transient changes in performance which may occur due to infrequent - processes or the low probability coincidence of two or more - processes. The performance must be evaluated periodically during - continuous testing, and this results in use of [RFC2889] Frame - Rate metrics instead of [RFC2544] Throughput (which requires - stopping traffic to allow time for all traffic to exit internal - queues). - - Future/planned test specs include: - - o Request/Response Performance Tests (TCP, UDP) which measure the - transaction rate through the switch. - - o Noisy Neighbour Tests, to understand the effects of resource - sharing on the performance of a virtual switch. - - o Tests derived from examination of ETSI NFV Draft GS IFA003 - requirements [IFA003] on characterization of acceleration - technologies applied to vswitches. - - - - -Tahhan, et al. Expires September 22, 2016 [Page 10] - -Internet-Draft Benchmarking vSwitches March 2016 - - - The flexibility of deployment of a virtual switch within a network - means that the BMWG IETF existing literature needs to be used to - characterize the performance of a switch in various deployment - scenarios. The deployment scenarios under consideration include: - - Physical port to virtual switch to physical port - - __ - +--------------------------------------------------+ | - | +--------------------+ | | - | | | | | - | | v | | Host - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires September 22, 2016 [Page 11] - -Internet-Draft Benchmarking vSwitches March 2016 - - - Physical port to virtual switch to VNF to virtual switch to physical - port - - __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ : | | - | | | | | Guest - | : v | | - | +---------------+ +---------------+ | | - | | logical port 0| | logical port 1| | | - +---+---------------+-----------+---------------+---+ __| - ^ : - | | - : v __ - +---+---------------+----------+---------------+---+ | - | | logical port 0| | logical port 1| | | - | +---------------+ +---------------+ | | - | ^ : | | - | | | | | Host - | : v | | - | +--------------+ +--------------+ | | - | | phy port | vSwitch | phy port | | | - +---+--------------+------------+--------------+---+ __| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - -Tahhan, et al. Expires September 22, 2016 [Page 12] - -Internet-Draft Benchmarking vSwitches March 2016 - - - Physical port to virtual switch to VNF to virtual switch to VNF to - virtual switch to physical port - - __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | ^ | | | ^ | | | - | | v | | | v | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 1 | | | | 0 1 | | | - +---+---------------+--+ +---+---------------+--+__| - ^ : ^ : - | | | | - : v : v _ - +---+---------------+---------+---------------+--+ | - | | 0 1 | | 3 4 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | ^ | ^ | | | Host - | | |-----------------| v | | - | +--------------+ +--------------+ | | - | | phy ports | vSwitch | phy ports | | | - +---+--------------+----------+--------------+---+_| - ^ : - | | - : v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - -Tahhan, et al. Expires September 22, 2016 [Page 13] - -Internet-Draft Benchmarking vSwitches March 2016 - - - Physical port to virtual switch to VNF - - __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | ^ | | - | | | | Guest - | : | | - | +---------------+ | | - | | logical port 0| | | - +---+---------------+-------------------------------+ __| - ^ - | - : __ - +---+---------------+------------------------------+ | - | | logical port 0| | | - | +---------------+ | | - | ^ | | - | | | | Host - | : | | - | +--------------+ | | - | | phy port | vSwitch | | - +---+--------------+------------ -------------- ---+ __| - ^ - | - : - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires September 22, 2016 [Page 14] - -Internet-Draft Benchmarking vSwitches March 2016 - - - VNF to virtual switch to physical port - - __ - +---------------------------------------------------+ | - | | | - | +-------------------------------------------+ | | - | | Application | | | - | +-------------------------------------------+ | | - | : | | - | | | | Guest - | v | | - | +---------------+ | | - | | logical port | | | - +-------------------------------+---------------+---+ __| - : - | - v __ - +------------------------------+---------------+---+ | - | | logical port | | | - | +---------------+ | | - | : | | - | | | | Host - | v | | - | +--------------+ | | - | vSwitch | phy port | | | - +-------------------------------+--------------+---+ __| - : - | - v - +--------------------------------------------------+ - | | - | traffic generator | - | | - +--------------------------------------------------+ - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires September 22, 2016 [Page 15] - -Internet-Draft Benchmarking vSwitches March 2016 - - - VNF to virtual switch to VNF - - __ - +----------------------+ +----------------------+ | - | Guest 1 | | Guest 2 | | - | +---------------+ | | +---------------+ | | - | | Application | | | | Application | | | - | +---------------+ | | +---------------+ | | - | | | | ^ | | - | v | | | | | Guests - | +---------------+ | | +---------------+ | | - | | logical ports | | | | logical ports | | | - | | 0 | | | | 0 | | | - +---+---------------+--+ +---+---------------+--+__| - : ^ - | | - v : _ - +---+---------------+---------+---------------+--+ | - | | 1 | | 1 | | | - | | logical ports | | logical ports | | | - | +---------------+ +---------------+ | | - | | ^ | | Host - | L-----------------+ | | - | | | - | vSwitch | | - +------------------------------------------------+_| - - A set of Deployment Scenario figures is available on the VSPERF Test - Methodology Wiki page [TestTopo]. - -5. 3x3 Matrix Coverage - - This section organizes the many existing test specifications into the - "3x3" matrix (introduced in [I-D.ietf-bmwg-virtual-net]). Because - the LTD specification ID names are quite long, this section is - organized into lists for each occupied cell of the matrix (not all - are occupied, also the matrix has grown to 3x4 to accommodate scale - metrics when displaying the coverage of many metrics/benchmarks). - The current version of the LTD specification is available [LTD]. - - The tests listed below assess the activation of paths in the data - plane, rather than the control plane. - - A complete list of tests with short summaries is available on the - VSPERF "LTD Test Spec Overview" Wiki page [LTDoverV]. - - - - - - -Tahhan, et al. Expires September 22, 2016 [Page 16] - -Internet-Draft Benchmarking vSwitches March 2016 - - -5.1. Speed of Activation - - o Activation.RFC2889.AddressLearningRate - - o PacketLatency.InitialPacketProcessingLatency - -5.2. Accuracy of Activation section - - o CPDP.Coupling.Flow.Addition - -5.3. Reliability of Activation - - o Throughput.RFC2544.SystemRecoveryTime - - o Throughput.RFC2544.ResetTime - -5.4. Scale of Activation - - o Activation.RFC2889.AddressCachingCapacity - -5.5. Speed of Operation - - o Throughput.RFC2544.PacketLossRate - - o CPU.RFC2544.0PacketLoss - - o Throughput.RFC2544.PacketLossRateFrameModification - - o Throughput.RFC2544.BackToBackFrames - - o Throughput.RFC2889.MaxForwardingRate - - o Throughput.RFC2889.ForwardPressure - - o Throughput.RFC2889.BroadcastFrameForwarding - -5.6. Accuracy of Operation - - o Throughput.RFC2889.ErrorFramesFiltering - - o Throughput.RFC2544.Profile - -5.7. Reliability of Operation - - o Throughput.RFC2889.Soak - - o Throughput.RFC2889.SoakFrameModification - - - - -Tahhan, et al. Expires September 22, 2016 [Page 17] - -Internet-Draft Benchmarking vSwitches March 2016 - - - o PacketDelayVariation.RFC3393.Soak - -5.8. Scalability of Operation - - o Scalability.RFC2544.0PacketLoss - - o MemoryBandwidth.RFC2544.0PacketLoss.Scalability - -5.9. Summary - -|------------------------------------------------------------------------| -| | | | | | -| | SPEED | ACCURACY | RELIABILITY | SCALE | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Activation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| Operation | X | X | X | X | -| | | | | | -|------------------------------------------------------------------------| -| | | | | | -| De-activation | | | | | -| | | | | | -|------------------------------------------------------------------------| - -6. Security Considerations - - Benchmarking activities as described in this memo are limited to - technology characterization of a Device Under Test/System Under Test - (DUT/SUT) using controlled stimuli in a laboratory environment, with - dedicated address space and the constraints specified in the sections - above. - - The benchmarking network topology will be an independent test setup - and MUST NOT be connected to devices that may forward the test - traffic into a production network, or misroute traffic to the test - management network. - - Further, benchmarking is performed on a "black-box" basis, relying - solely on measurements observable external to the DUT/SUT. - - Special capabilities SHOULD NOT exist in the DUT/SUT specifically for - benchmarking purposes. Any implications for network security arising - from the DUT/SUT SHOULD be identical in the lab and in production - networks. - - - -Tahhan, et al. Expires September 22, 2016 [Page 18] - -Internet-Draft Benchmarking vSwitches March 2016 - - -7. IANA Considerations - - No IANA Action is requested at this time. - -8. Acknowledgements - - The authors appreciate and acknowledge comments from Scott Bradner, - Marius Georgescu, Ramki Krishnan, Doug Montgomery, Martin Klozik, - Christian Trautman, and others for their reviews. - -9. References - -9.1. Normative References - - [NFV.PER001] - "Network Function Virtualization: Performance and - Portability Best Practices", Group Specification ETSI GS - NFV-PER 001 V1.1.1 (2014-06), June 2014. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - <http://www.rfc-editor.org/info/rfc2119>. - - [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN - Switching Devices", RFC 2285, DOI 10.17487/RFC2285, - February 1998, <http://www.rfc-editor.org/info/rfc2285>. - - [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, - "Framework for IP Performance Metrics", RFC 2330, - DOI 10.17487/RFC2330, May 1998, - <http://www.rfc-editor.org/info/rfc2330>. - - [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for - Network Interconnect Devices", RFC 2544, - DOI 10.17487/RFC2544, March 1999, - <http://www.rfc-editor.org/info/rfc2544>. - - [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way - Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, - September 1999, <http://www.rfc-editor.org/info/rfc2679>. - - [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way - Packet Loss Metric for IPPM", RFC 2680, - DOI 10.17487/RFC2680, September 1999, - <http://www.rfc-editor.org/info/rfc2680>. - - - - - -Tahhan, et al. Expires September 22, 2016 [Page 19] - -Internet-Draft Benchmarking vSwitches March 2016 - - - [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip - Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, - September 1999, <http://www.rfc-editor.org/info/rfc2681>. - - [RFC2889] Mandeville, R. and J. Perser, "Benchmarking Methodology - for LAN Switching Devices", RFC 2889, - DOI 10.17487/RFC2889, August 2000, - <http://www.rfc-editor.org/info/rfc2889>. - - [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation - Metric for IP Performance Metrics (IPPM)", RFC 3393, - DOI 10.17487/RFC3393, November 2002, - <http://www.rfc-editor.org/info/rfc3393>. - - [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network - performance measurement with periodic streams", RFC 3432, - DOI 10.17487/RFC3432, November 2002, - <http://www.rfc-editor.org/info/rfc3432>. - - [RFC3918] Stopp, D. and B. Hickman, "Methodology for IP Multicast - Benchmarking", RFC 3918, DOI 10.17487/RFC3918, October - 2004, <http://www.rfc-editor.org/info/rfc3918>. - - [RFC4689] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, - "Terminology for Benchmarking Network-layer Traffic - Control Mechanisms", RFC 4689, DOI 10.17487/RFC4689, - October 2006, <http://www.rfc-editor.org/info/rfc4689>. - - [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, - S., and J. Perser, "Packet Reordering Metrics", RFC 4737, - DOI 10.17487/RFC4737, November 2006, - <http://www.rfc-editor.org/info/rfc4737>. - - [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. - Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", - RFC 5357, DOI 10.17487/RFC5357, October 2008, - <http://www.rfc-editor.org/info/rfc5357>. - - [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, - "Network Time Protocol Version 4: Protocol and Algorithms - Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, - <http://www.rfc-editor.org/info/rfc5905>. - - [RFC6201] Asati, R., Pignataro, C., Calabria, F., and C. Olvera, - "Device Reset Characterization", RFC 6201, - DOI 10.17487/RFC6201, March 2011, - <http://www.rfc-editor.org/info/rfc6201>. - - - - -Tahhan, et al. Expires September 22, 2016 [Page 20] - -Internet-Draft Benchmarking vSwitches March 2016 - - -9.2. Informative References - - [BrahRel] "Brahmaputra, Second OPNFV Release https://www.opnfv.org/ - brahmaputra". - - [I-D.huang-bmwg-virtual-network-performance] - Huang, L., Rong, G., Mandeville, B., and B. Hickman, - "Benchmarking Methodology for Virtualization Network - Performance", draft-huang-bmwg-virtual-network- - performance-01 (work in progress), April 2015. - - [I-D.ietf-bmwg-virtual-net] - Morton, A., "Considerations for Benchmarking Virtual - Network Functions and Their Infrastructure", draft-ietf- - bmwg-virtual-net-02 (work in progress), March 2016. - - [IFA003] "https://docbox.etsi.org/ISG/NFV/Open/Drafts/ - IFA003_Acceleration_-_vSwitch_Spec/". - - [LTD] "LTD Test Specification - http://artifacts.opnfv.org/vswitchperf/docs/requirements/ - index.html". - - [LTDoverV] - "LTD Test Spec Overview https://wiki.opnfv.org/wiki/ - vswitchperf_test_spec_review". - - [RFC1242] Bradner, S., "Benchmarking Terminology for Network - Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, - July 1991, <http://www.rfc-editor.org/info/rfc1242>. - - [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation - Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, - March 2009, <http://www.rfc-editor.org/info/rfc5481>. - - [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of - Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, - <http://www.rfc-editor.org/info/rfc6049>. - - [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics - (IPPM) Registry of Metrics Are Obsolete", RFC 6248, - DOI 10.17487/RFC6248, April 2011, - <http://www.rfc-editor.org/info/rfc6248>. - - [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New - Performance Metric Development", BCP 170, RFC 6390, - DOI 10.17487/RFC6390, October 2011, - <http://www.rfc-editor.org/info/rfc6390>. - - - -Tahhan, et al. Expires September 22, 2016 [Page 21] - -Internet-Draft Benchmarking vSwitches March 2016 - - - [TestTopo] - "Test Topologies https://wiki.opnfv.org/vsperf/ - test_methodology". - -Authors' Addresses - - Maryam Tahhan - Intel - - Email: maryam.tahhan@intel.com - - - Billy O'Mahony - Intel - - Email: billy.o.mahony@intel.com - - - Al Morton - AT&T Labs - 200 Laurel Avenue South - Middletown,, NJ 07748 - USA - - Phone: +1 732 420 1571 - Fax: +1 732 368 1192 - Email: acmorton@att.com - URI: http://home.comcast.net/~acmacm/ - - - - - - - - - - - - - - - - - - - - - - - -Tahhan, et al. Expires September 22, 2016 [Page 22] diff --git a/docs/userguide/testusage.rst b/docs/userguide/testusage.rst index c55b5a2c..ce647c6b 100755 --- a/docs/userguide/testusage.rst +++ b/docs/userguide/testusage.rst @@ -85,6 +85,10 @@ contents. Any configuration item mentioned in any .conf file in ``./conf`` directory can be added and that item will be overridden by the custom configuration value. +Further details about configuration files evaluation and special behaviour +of options with ``GUEST_`` prefix could be found at `design document +<http://artifacts.opnfv.org/vswitchperf/docs/design/vswitchperf_design.html#configuration>`__. + Using a custom settings file ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -105,11 +109,15 @@ described like so (1 = max priority): 2. Environment variables 3. Configuration file(s) +Further details about configuration files evaluation and special behaviour +of options with ``GUEST_`` prefix could be found at `design document +<http://artifacts.opnfv.org/vswitchperf/docs/design/vswitchperf_design.html#configuration>`__. + vloop_vnf ^^^^^^^^^ -vsperf uses a VM called vloop_vnf for looping traffic in the PVP and PVVP -deployment scenarios. The image can be downloaded from +vsperf uses a VM image called vloop_vnf for looping traffic in the deployment +scenarios involving VMs. The image can be downloaded from `<http://artifacts.opnfv.org/>`__. .. code-block:: console @@ -226,8 +234,8 @@ set the ports. $ ./vsperf --vswitch OvsVanilla -Executing PVP and PVVP tests -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Executing tests with VMs +^^^^^^^^^^^^^^^^^^^^^^^^ To run tests using vhost-user as guest access method: @@ -252,8 +260,8 @@ To run tests using vhost-user as guest access method: $ ./vsperf --conf-file=<path_to_custom_conf>/10_custom.conf -Executing PVP tests using Vanilla OVS -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Executing tests with VMs using Vanilla OVS +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ To run tests using Vanilla OVS: @@ -391,15 +399,15 @@ deployment. .. _guest-loopback-application: -Selection of loopback application for PVP and PVVP tests -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Selection of loopback application for tests with VMs +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ To select loopback application, which will perform traffic forwarding inside VM, following configuration parameter should be configured: .. code-block:: console - GUEST_LOOPBACK = ['testpmd', 'testpmd'] + GUEST_LOOPBACK = ['testpmd'] or use --test-param @@ -419,9 +427,16 @@ Supported loopback applications are: ensure traffic forwarding between its interfaces Guest loopback application must be configured, otherwise traffic -will not be forwarded by VM and testcases with PVP and PVVP deployments +will not be forwarded by VM and testcases with VM related deployments will fail. Guest loopback application is set to 'testpmd' by default. +Note: In case that only 1 or more than 2 NICs are configured for VM, +then 'testpmd' should be used. As it is able to forward traffic between +multiple VM NIC pairs. + +Note: In case of linux_bridge, all guest NICs are connected to the same +bridge inside the guest. + Multi-Queue Configuration ^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -622,8 +637,8 @@ OVS with DPDK and QEMU If you encounter the following error: "before (last 100 chars): '-path=/dev/hugepages,share=on: unable to map backing store for -hugepages: Cannot allocate memory\r\n\r\n" with the PVP or PVVP -deployment scenario, check the amount of hugepages on your system: +hugepages: Cannot allocate memory\r\n\r\n" during qemu initialization, +check the amount of hugepages on your system: .. code-block:: console diff --git a/src/dpdk/dpdk.py b/src/dpdk/dpdk.py index 477c1de4..bd9bb9cf 100644 --- a/src/dpdk/dpdk.py +++ b/src/dpdk/dpdk.py @@ -25,8 +25,8 @@ import subprocess import logging import glob -from tools import tasks from conf import settings +from tools import tasks from tools.module_manager import ModuleManager _LOGGER = logging.getLogger(__name__) @@ -150,7 +150,7 @@ def _remove_vhost_net(): def _vhost_user_cleanup(): """Remove files created by vhost-user tests. """ - for sock in settings.getValue('VHOST_USER_SOCKS'): + for sock in glob.glob(settings.getValue('VHOST_USER_SOCKS')): if os.path.exists(sock): try: tasks.run_task(['sudo', 'rm', sock], diff --git a/testcases/testcase.py b/testcases/testcase.py index 0123b305..6e215b46 100644 --- a/testcases/testcase.py +++ b/testcases/testcase.py @@ -57,7 +57,6 @@ class TestCase(object): self._loadgen = None self._output_file = None self._tc_results = None - self.guest_loopback = [] self._settings_original = {} self._settings_paths_modified = False self._testcast_run_time = None @@ -70,7 +69,8 @@ class TestCase(object): # update global settings guest_loopback = get_test_param('guest_loopback', None) if guest_loopback: - self._update_settings('GUEST_LOOPBACK', [guest_loopback for dummy in S.getValue('GUEST_LOOPBACK')]) + # we can put just one item, it'll be expanded automatically for all VMs + self._update_settings('GUEST_LOOPBACK', [guest_loopback]) if 'VSWITCH' in self._settings_original or 'VNF' in self._settings_original: self._settings_original.update({ @@ -112,12 +112,6 @@ class TestCase(object): self._tunnel_type = get_test_param('tunnel_type', self._tunnel_type) - # identify guest loopback method, so it can be added into reports - if self.deployment == 'pvp': - self.guest_loopback.append(S.getValue('GUEST_LOOPBACK')[0]) - else: - self.guest_loopback = S.getValue('GUEST_LOOPBACK').copy() - # read configuration of streams; CLI parameter takes precedence to # testcase definition multistream = cfg.get('MultiStream', TRAFFIC_DEFAULTS['multistream']) @@ -153,13 +147,6 @@ class TestCase(object): # Packet Forwarding mode self._vswitch_none = 'none' == S.getValue('VSWITCH').strip().lower() - # OVS Vanilla requires guest VM MAC address and IPs to work - if 'linux_bridge' in self.guest_loopback: - self._traffic['l2'].update({'srcmac': S.getValue('VANILLA_TGEN_PORT1_MAC'), - 'dstmac': S.getValue('VANILLA_TGEN_PORT2_MAC')}) - self._traffic['l3'].update({'srcip': S.getValue('VANILLA_TGEN_PORT1_IP'), - 'dstip': S.getValue('VANILLA_TGEN_PORT2_IP')}) - # trafficgen configuration required for tests of tunneling protocols if self.deployment == "op2p": self._traffic['l2'].update({'srcmac': @@ -192,13 +179,6 @@ class TestCase(object): # mount hugepages if needed self._mount_hugepages() - # verify enough hugepages are free to run the testcase - if not self._check_for_enough_hugepages(): - raise RuntimeError('Not enough hugepages free to run test.') - - # copy sources of l2 forwarding tools into VM shared dir if needed - self._copy_fwd_tools_for_all_guests() - self._logger.debug("Controllers:") loader = Loader() self._traffic_ctl = component_factory.create_traffic( @@ -209,6 +189,32 @@ class TestCase(object): self.deployment, loader.get_vnf_class()) + # verify enough hugepages are free to run the testcase + if not self._check_for_enough_hugepages(): + raise RuntimeError('Not enough hugepages free to run test.') + + # perform guest related handling + if self._vnf_ctl.get_vnfs_number(): + # copy sources of l2 forwarding tools into VM shared dir if needed + self._copy_fwd_tools_for_all_guests() + + # in case of multi VM in parallel, set the number of streams to the number of VMs + if self.deployment.startswith('pvpv'): + # for each VM NIC pair we need an unique stream + streams = 0 + for vm_nic in S.getValue('GUEST_NICS_NR')[:self._vnf_ctl.get_vnfs_number()]: + streams += int(vm_nic / 2) if vm_nic > 1 else 1 + self._logger.debug("VMs with parallel connection were detected. " + "Thus Number of streams was set to %s", streams) + self._traffic.update({'multistream': streams}) + + # OVS Vanilla requires guest VM MAC address and IPs to work + if 'linux_bridge' in S.getValue('GUEST_LOOPBACK'): + self._traffic['l2'].update({'srcmac': S.getValue('VANILLA_TGEN_PORT1_MAC'), + 'dstmac': S.getValue('VANILLA_TGEN_PORT2_MAC')}) + self._traffic['l3'].update({'srcip': S.getValue('VANILLA_TGEN_PORT1_IP'), + 'dstip': S.getValue('VANILLA_TGEN_PORT2_IP')}) + if self._vswitch_none: self._vswitch_ctl = component_factory.create_pktfwd( self.deployment, @@ -350,8 +356,8 @@ class TestCase(object): item[ResultsConstants.SCAL_STREAM_COUNT] = self._traffic['multistream'] item[ResultsConstants.SCAL_STREAM_TYPE] = self._traffic['stream_type'] item[ResultsConstants.SCAL_PRE_INSTALLED_FLOWS] = self._traffic['pre_installed_flows'] - if self.deployment in ['pvp', 'pvvp'] and len(self.guest_loopback): - item[ResultsConstants.GUEST_LOOPBACK] = ' '.join(self.guest_loopback) + if self._vnf_ctl.get_vnfs_number(): + item[ResultsConstants.GUEST_LOOPBACK] = ' '.join(S.getValue('GUEST_LOOPBACK')) if self._tunnel_type: item[ResultsConstants.TUNNEL_TYPE] = self._tunnel_type return results @@ -359,19 +365,15 @@ class TestCase(object): def _copy_fwd_tools_for_all_guests(self): """Copy dpdk and l2fwd code to GUEST_SHARE_DIR[s] based on selected deployment. """ - # data are copied only for pvp and pvvp, so let's count number of 'v' - counter = 1 - while counter <= self.deployment.count('v'): - self._copy_fwd_tools_for_guest(counter) - counter += 1 + # consider only VNFs involved in the test + for guest_dir in set(S.getValue('GUEST_SHARE_DIR')[:self._vnf_ctl.get_vnfs_number()]): + self._copy_fwd_tools_for_guest(guest_dir) - def _copy_fwd_tools_for_guest(self, index): + def _copy_fwd_tools_for_guest(self, guest_dir): """Copy dpdk and l2fwd code to GUEST_SHARE_DIR of VM :param index: Index of VM starting from 1 (i.e. 1st VM has index 1) """ - guest_dir = S.getValue('GUEST_SHARE_DIR')[index-1] - # remove shared dir if it exists to avoid issues with file consistency if os.path.exists(guest_dir): tasks.run_task(['rm', '-f', '-r', guest_dir], self._logger, @@ -381,7 +383,8 @@ class TestCase(object): os.makedirs(guest_dir) # copy sources into shared dir only if neccessary - if 'testpmd' in self.guest_loopback or 'l2fwd' in self.guest_loopback: + guest_loopback = set(S.getValue('GUEST_LOOPBACK')) + if 'testpmd' in guest_loopback or 'l2fwd' in guest_loopback: try: tasks.run_task(['rsync', '-a', '-r', '-l', r'--exclude="\.git"', os.path.join(S.getValue('RTE_SDK_USER'), ''), @@ -423,8 +426,8 @@ class TestCase(object): """ hugepages_needed = 0 hugepage_size = hugepages.get_hugepage_size() - # get hugepage amounts per guest - for guest in range(self.deployment.count('v')): + # get hugepage amounts per guest involved in the test + for guest in range(self._vnf_ctl.get_vnfs_number()): hugepages_needed += math.ceil((int(S.getValue( 'GUEST_MEMORY')[guest]) * 1000) / hugepage_size) @@ -436,7 +439,7 @@ class TestCase(object): from vswitches import ovs_dpdk_vhost if ovs_dpdk_vhost.OvsDpdkVhost.old_dpdk_config(): match = re.search( - '-socket-mem\s+(\d+),(\d+)', + r'-socket-mem\s+(\d+),(\d+)', ''.join(S.getValue('VSWITCHD_DPDK_ARGS'))) if match: sock0_mem, sock1_mem = (int(match.group(1)) * 1024 / hugepage_size, diff --git a/vnfs/qemu/qemu.py b/vnfs/qemu/qemu.py index 2093cb3b..c9569ae6 100644 --- a/vnfs/qemu/qemu.py +++ b/vnfs/qemu/qemu.py @@ -32,7 +32,7 @@ class IVnfQemu(IVnf): Abstract class for controling an instance of QEMU """ _cmd = None - _expect = S.getValue('GUEST_PROMPT_LOGIN') + _expect = None _proc_name = 'qemu' class GuestCommandFilter(logging.Filter): @@ -47,28 +47,32 @@ class IVnfQemu(IVnf): Initialisation function. """ super(IVnfQemu, self).__init__() + + self._expect = S.getValue('GUEST_PROMPT_LOGIN')[self._number] self._logger = logging.getLogger(__name__) self._logfile = os.path.join( S.getValue('LOG_DIR'), S.getValue('LOG_FILE_QEMU')) + str(self._number) self._timeout = S.getValue('GUEST_TIMEOUT')[self._number] self._monitor = '%s/vm%dmonitor' % ('/tmp', self._number) - self._net1 = get_test_param('guest_nic1_name', None) - if self._net1 == None: - self._net1 = S.getValue('GUEST_NIC1_NAME')[self._number] - else: - self._net1 = self._net1.split(',')[self._number] - self._net2 = get_test_param('guest_nic2_name', None) - if self._net2 == None: - self._net2 = S.getValue('GUEST_NIC2_NAME')[self._number] - else: - self._net2 = self._net2.split(',')[self._number] + # read GUEST NICs configuration and use only defined NR of NICS + nics_nr = S.getValue('GUEST_NICS_NR')[self._number] + # and inform user about missconfiguration + if nics_nr < 1: + raise RuntimeError('At least one VM NIC is mandotory, but {} ' + 'NICs are configured'.format(nics_nr)) + elif nics_nr > 1 and nics_nr % 2: + nics_nr = int(nics_nr / 2) * 2 + self._logger.warning('Odd number of NICs is configured, only ' + '%s NICs will be used', nics_nr) + + self._nics = S.getValue('GUEST_NICS')[self._number][:nics_nr] # set guest loopback application based on VNF configuration # cli option take precedence to config file values self._guest_loopback = S.getValue('GUEST_LOOPBACK')[self._number] - self._testpmd_fwd_mode = S.getValue('GUEST_TESTPMD_FWD_MODE') + self._testpmd_fwd_mode = S.getValue('GUEST_TESTPMD_FWD_MODE')[self._number] # in case of SRIOV we must ensure, that MAC addresses are not swapped if S.getValue('SRIOV_ENABLED') and self._testpmd_fwd_mode.startswith('mac') and \ not S.getValue('VNF').endswith('PciPassthrough'): @@ -86,7 +90,7 @@ class IVnfQemu(IVnf): '-smp', str(S.getValue('GUEST_SMP')[self._number]), '-cpu', 'host,migratable=off', '-drive', 'if={},file='.format(S.getValue( - 'GUEST_BOOT_DRIVE_TYPE')) + + 'GUEST_BOOT_DRIVE_TYPE')[self._number]) + S.getValue('GUEST_IMAGE')[self._number], '-boot', 'c', '--enable-kvm', '-monitor', 'unix:%s,server,nowait' % self._monitor, @@ -99,7 +103,7 @@ class IVnfQemu(IVnf): '-snapshot', '-net none', '-no-reboot', '-drive', 'if=%s,format=raw,file=fat:rw:%s,snapshot=off' % - (S.getValue('GUEST_SHARED_DRIVE_TYPE'), + (S.getValue('GUEST_SHARED_DRIVE_TYPE')[self._number], S.getValue('GUEST_SHARE_DIR')[self._number]), ] self._configure_logging() @@ -181,11 +185,11 @@ class IVnfQemu(IVnf): if not self._timeout: self._expect_process(timeout=timeout) - self._child.sendline(S.getValue('GUEST_USERNAME')) - self._child.expect(S.getValue('GUEST_PROMPT_PASSWORD'), timeout=5) - self._child.sendline(S.getValue('GUEST_PASSWORD')) + self._child.sendline(S.getValue('GUEST_USERNAME')[self._number]) + self._child.expect(S.getValue('GUEST_PROMPT_PASSWORD')[self._number], timeout=5) + self._child.sendline(S.getValue('GUEST_PASSWORD')[self._number]) - self._expect_process(S.getValue('GUEST_PROMPT'), timeout=5) + self._expect_process(S.getValue('GUEST_PROMPT')[self._number], timeout=5) def send_and_pass(self, cmd, timeout=30): """ @@ -197,10 +201,10 @@ class IVnfQemu(IVnf): :returns: None """ self.execute(cmd) - self.wait(S.getValue('GUEST_PROMPT'), timeout=timeout) + self.wait(S.getValue('GUEST_PROMPT')[self._number], timeout=timeout) self.execute('echo $?') self._child.expect('^0$', timeout=1) # expect a 0 - self.wait(S.getValue('GUEST_PROMPT'), timeout=timeout) + self.wait(S.getValue('GUEST_PROMPT')[self._number], timeout=timeout) def _affinitize(self): """ @@ -284,11 +288,14 @@ class IVnfQemu(IVnf): self._logger.error('Unsupported guest loopback method "%s" was specified. Option' ' "buildin" will be used as a fallback.', self._guest_loopback) - def wait(self, prompt=S.getValue('GUEST_PROMPT'), timeout=30): + def wait(self, prompt=None, timeout=30): + if prompt is None: + prompt = S.getValue('GUEST_PROMPT')[self._number] super(IVnfQemu, self).wait(prompt=prompt, timeout=timeout) - def execute_and_wait(self, cmd, timeout=30, - prompt=S.getValue('GUEST_PROMPT')): + def execute_and_wait(self, cmd, timeout=30, prompt=None): + if prompt is None: + prompt = S.getValue('GUEST_PROMPT')[self._number] super(IVnfQemu, self).execute_and_wait(cmd, timeout=timeout, prompt=prompt) @@ -304,13 +311,13 @@ class IVnfQemu(IVnf): """ # mount shared directory self.execute_and_wait('umount /dev/sdb1') - self.execute_and_wait('rm -rf ' + S.getValue('GUEST_OVS_DPDK_DIR')) - self.execute_and_wait('mkdir -p ' + S.getValue('OVS_DPDK_SHARE')) + self.execute_and_wait('rm -rf ' + S.getValue('GUEST_OVS_DPDK_DIR')[self._number]) + self.execute_and_wait('mkdir -p ' + S.getValue('GUEST_OVS_DPDK_SHARE')[self._number]) self.execute_and_wait('mount -o ro,iocharset=utf8 /dev/sdb1 ' + - S.getValue('OVS_DPDK_SHARE')) - self.execute_and_wait('mkdir -p ' + S.getValue('GUEST_OVS_DPDK_DIR')) - self.execute_and_wait('cp -r ' + os.path.join(S.getValue('OVS_DPDK_SHARE'), dirname) + - ' ' + S.getValue('GUEST_OVS_DPDK_DIR')) + S.getValue('GUEST_OVS_DPDK_SHARE')[self._number]) + self.execute_and_wait('mkdir -p ' + S.getValue('GUEST_OVS_DPDK_DIR')[self._number]) + self.execute_and_wait('cp -r ' + os.path.join(S.getValue('GUEST_OVS_DPDK_SHARE')[self._number], dirname) + + ' ' + S.getValue('GUEST_OVS_DPDK_DIR')[self._number]) self.execute_and_wait('umount /dev/sdb1') def _configure_disable_firewall(self): @@ -343,7 +350,7 @@ class IVnfQemu(IVnf): # Guest images _should_ have 1024 hugepages by default, # but just in case:''' - self.execute_and_wait('sysctl vm.nr_hugepages=1024') + self.execute_and_wait('sysctl vm.nr_hugepages={}'.format(S.getValue('GUEST_HUGEPAGES_NR')[self._number])) # Mount hugepages self.execute_and_wait('mkdir -p /dev/hugepages') @@ -351,19 +358,19 @@ class IVnfQemu(IVnf): 'mount -t hugetlbfs hugetlbfs /dev/hugepages') # build and configure system for dpdk - self.execute_and_wait('cd ' + S.getValue('GUEST_OVS_DPDK_DIR') + + self.execute_and_wait('cd ' + S.getValue('GUEST_OVS_DPDK_DIR')[self._number] + '/DPDK') self.execute_and_wait('export CC=gcc') self.execute_and_wait('export RTE_SDK=' + - S.getValue('GUEST_OVS_DPDK_DIR') + '/DPDK') + S.getValue('GUEST_OVS_DPDK_DIR')[self._number] + '/DPDK') self.execute_and_wait('export RTE_TARGET=%s' % S.getValue('RTE_TARGET')) # modify makefile if needed self._modify_dpdk_makefile() # disable network interfaces, so DPDK can take care of them - self.execute_and_wait('ifdown ' + self._net1) - self.execute_and_wait('ifdown ' + self._net2) + for nic in self._nics: + self.execute_and_wait('ifdown ' + nic['device']) # build and insert igb_uio and rebind interfaces to it self.execute_and_wait('make RTE_OUTPUT=$RTE_SDK/$RTE_TARGET -C ' @@ -372,35 +379,30 @@ class IVnfQemu(IVnf): self.execute_and_wait('insmod %s/kmod/igb_uio.ko' % S.getValue('RTE_TARGET')) self.execute_and_wait('./tools/dpdk*bind.py --status') - self.execute_and_wait( - './tools/dpdk*bind.py -u' ' ' + - S.getValue('GUEST_NET1_PCI_ADDRESS')[self._number] + ' ' + - S.getValue('GUEST_NET2_PCI_ADDRESS')[self._number]) - self.execute_and_wait( - './tools/dpdk*bind.py -b igb_uio' ' ' + - S.getValue('GUEST_NET1_PCI_ADDRESS')[self._number] + ' ' + - S.getValue('GUEST_NET2_PCI_ADDRESS')[self._number]) + pci_list = ' '.join([nic['pci'] for nic in self._nics]) + self.execute_and_wait('./tools/dpdk*bind.py -u ' + pci_list) + self.execute_and_wait('./tools/dpdk*bind.py -b igb_uio ' + pci_list) self.execute_and_wait('./tools/dpdk*bind.py --status') # build and run 'test-pmd' - self.execute_and_wait('cd ' + S.getValue('GUEST_OVS_DPDK_DIR') + + self.execute_and_wait('cd ' + S.getValue('GUEST_OVS_DPDK_DIR')[self._number] + '/DPDK/app/test-pmd') self.execute_and_wait('make clean') self.execute_and_wait('make') - if int(S.getValue('GUEST_NIC_QUEUES')): + if int(S.getValue('GUEST_NIC_QUEUES')[self._number]): self.execute_and_wait( './testpmd {} -n4 --socket-mem 512 --'.format( - S.getValue('GUEST_TESTPMD_CPU_MASK')) + + S.getValue('GUEST_TESTPMD_CPU_MASK')[self._number]) + ' --burst=64 -i --txqflags=0xf00 ' + '--nb-cores={} --rxq={} --txq={} '.format( - S.getValue('GUEST_TESTPMD_NB_CORES'), - S.getValue('GUEST_TESTPMD_TXQ'), - S.getValue('GUEST_TESTPMD_RXQ')) + + S.getValue('GUEST_TESTPMD_NB_CORES')[self._number], + S.getValue('GUEST_TESTPMD_TXQ')[self._number], + S.getValue('GUEST_TESTPMD_RXQ')[self._number]) + '--disable-hw-vlan', 60, "Done") else: self.execute_and_wait( './testpmd {} -n 4 --socket-mem 512 --'.format( - S.getValue('GUEST_TESTPMD_CPU_MASK')) + + S.getValue('GUEST_TESTPMD_CPU_MASK')[self._number]) + ' --burst=64 -i --txqflags=0xf00 ' + '--disable-hw-vlan', 60, "Done") self.execute('set fwd ' + self._testpmd_fwd_mode, 1) @@ -411,44 +413,51 @@ class IVnfQemu(IVnf): """ Configure VM to perform L2 forwarding between NICs by l2fwd module """ - if int(S.getValue('GUEST_NIC_QUEUES')): + if int(S.getValue('GUEST_NIC_QUEUES')[self._number]): self._set_multi_queue_nic() self._configure_copy_sources('l2fwd') self._configure_disable_firewall() + # configure all interfaces + for nic in self._nics: + self.execute('ip addr add ' + + nic['ip'] + ' dev ' + nic['device']) + self.execute('ip link set dev ' + nic['device'] + ' up') + # build and configure system for l2fwd - self.execute_and_wait('cd ' + S.getValue('GUEST_OVS_DPDK_DIR') + + self.execute_and_wait('cd ' + S.getValue('GUEST_OVS_DPDK_DIR')[self._number] + '/l2fwd') self.execute_and_wait('export CC=gcc') self.execute_and_wait('make') - self.execute_and_wait('insmod ' + S.getValue('GUEST_OVS_DPDK_DIR') + - '/l2fwd' + '/l2fwd.ko net1=' + self._net1 + - ' net2=' + self._net2) + if len(self._nics) == 2: + self.execute_and_wait('insmod ' + S.getValue('GUEST_OVS_DPDK_DIR')[self._number] + + '/l2fwd' + '/l2fwd.ko net1=' + self._nics[0]['device'] + + ' net2=' + self._nics[1]['device']) + else: + raise RuntimeError('l2fwd can forward only between 2 NICs, but {} NICs are ' + 'configured inside GUEST'.format(len(self._nics))) def _configure_linux_bridge(self): """ Configure VM to perform L2 forwarding between NICs by linux bridge """ - if int(S.getValue('GUEST_NIC_QUEUES')): + if int(S.getValue('GUEST_NIC_QUEUES')[self._number]): self._set_multi_queue_nic() self._configure_disable_firewall() - self.execute('ip addr add ' + - S.getValue('VANILLA_NIC1_IP_CIDR')[self._number] + - ' dev ' + self._net1) - self.execute('ip link set dev ' + self._net1 + ' up') - - self.execute('ip addr add ' + - S.getValue('VANILLA_NIC2_IP_CIDR')[self._number] + - ' dev ' + self._net2) - self.execute('ip link set dev ' + self._net2 + ' up') - # configure linux bridge self.execute('brctl addbr br0') - self.execute('brctl addif br0 ' + self._net1 + ' ' + self._net2) + + # add all NICs into the bridge + for nic in self._nics: + self.execute('ip addr add ' + + nic['ip'] + ' dev ' + nic['device']) + self.execute('ip link set dev ' + nic['device'] + ' up') + self.execute('brctl addif br0 ' + nic['device']) + self.execute('ip addr add ' + - S.getValue('VANILLA_BRIDGE_IP')[self._number] + + S.getValue('GUEST_BRIDGE_IP')[self._number] + ' dev br0') self.execute('ip link set dev br0 up') @@ -474,17 +483,15 @@ class IVnfQemu(IVnf): # Controls source route verification # 0 means no source validation self.execute('sysctl -w net.ipv4.conf.all.rp_filter=0') - self.execute('sysctl -w net.ipv4.conf.' + self._net1 + '.rp_filter=0') - self.execute('sysctl -w net.ipv4.conf.' + self._net2 + '.rp_filter=0') + for nic in self._nics: + self.execute('sysctl -w net.ipv4.conf.' + nic['device'] + '.rp_filter=0') def _set_multi_queue_nic(self): """ Enable multi-queue in guest kernel with ethool. :return: None """ - self.execute_and_wait('ethtool -L {} combined {}'.format( - self._net1, S.getValue('GUEST_NIC_QUEUES'))) - self.execute_and_wait('ethtool -l {}'.format(self._net1)) - self.execute_and_wait('ethtool -L {} combined {}'.format( - self._net2, S.getValue('GUEST_NIC_QUEUES'))) - self.execute_and_wait('ethtool -l {}'.format(self._net2)) + for nic in self._nics: + self.execute_and_wait('ethtool -L {} combined {}'.format( + nic['device'], S.getValue('GUEST_NIC_QUEUES')[self._number])) + self.execute_and_wait('ethtool -l {}'.format(nic['device'])) diff --git a/vnfs/qemu/qemu_dpdk_vhost_user.py b/vnfs/qemu/qemu_dpdk_vhost_user.py index 49131423..fc46aba1 100644 --- a/vnfs/qemu/qemu_dpdk_vhost_user.py +++ b/vnfs/qemu/qemu_dpdk_vhost_user.py @@ -31,45 +31,36 @@ class QemuDpdkVhostUser(IVnfQemu): super(QemuDpdkVhostUser, self).__init__() self._logger = logging.getLogger(__name__) - # calculate indexes of guest devices (e.g. charx, dpdkvhostuserx) - i = self._number * 2 - if1 = str(i) - if2 = str(i + 1) - net1 = 'net' + str(i + 1) - net2 = 'net' + str(i + 2) - # multi-queue values - if int(S.getValue('GUEST_NIC_QUEUES')): - queue_str = ',queues={}'.format(S.getValue('GUEST_NIC_QUEUES')) + if int(S.getValue('GUEST_NIC_QUEUES')[self._number]): + queue_str = ',queues={}'.format(S.getValue('GUEST_NIC_QUEUES')[self._number]) mq_vector_str = ',mq=on,vectors={}'.format( - int(S.getValue('GUEST_NIC_QUEUES')) * 2 + 2) + int(S.getValue('GUEST_NIC_QUEUES')[self._number]) * 2 + 2) else: queue_str, mq_vector_str = '', '' - self._cmd += ['-chardev', - 'socket,id=char' + if1 + - ',path=' + S.getValue('OVS_VAR_DIR') + - 'dpdkvhostuser' + if1, - '-chardev', - 'socket,id=char' + if2 + - ',path=' + S.getValue('OVS_VAR_DIR') + - 'dpdkvhostuser' + if2, - '-netdev', - 'type=vhost-user,id=' + net1 + - ',chardev=char' + if1 + ',vhostforce' + queue_str, - '-device', - 'virtio-net-pci,mac=' + - S.getValue('GUEST_NET1_MAC')[self._number] + - ',netdev=' + net1 + ',csum=off,gso=off,' + - 'guest_tso4=off,guest_tso6=off,guest_ecn=off' + - mq_vector_str, - '-netdev', - 'type=vhost-user,id=' + net2 + - ',chardev=char' + if2 + ',vhostforce' + queue_str, - '-device', - 'virtio-net-pci,mac=' + - S.getValue('GUEST_NET2_MAC')[self._number] + - ',netdev=' + net2 + ',csum=off,gso=off,' + - 'guest_tso4=off,guest_tso6=off,guest_ecn=off' + - mq_vector_str, - ] + # calculate index of first interface, i.e. check how many + # interfaces has been created for previous VMs, where 1st NIC + # of 1st VM has index 0 + start_index = sum(S.getValue('GUEST_NICS_NR')[:self._number]) + + # setup requested number of interfaces + for nic in range(len(self._nics)): + index = start_index + nic + ifi = str(index) + net = 'net' + str(index + 1) + + self._cmd += ['-chardev', + 'socket,id=char' + ifi + + ',path=' + S.getValue('OVS_VAR_DIR') + + 'dpdkvhostuser' + ifi, + '-netdev', + 'type=vhost-user,id=' + net + + ',chardev=char' + ifi + ',vhostforce' + queue_str, + '-device', + 'virtio-net-pci,mac=' + + self._nics[nic]['mac'] + + ',netdev=' + net + ',csum=off,gso=off,' + + 'guest_tso4=off,guest_tso6=off,guest_ecn=off' + + mq_vector_str, + ] diff --git a/vnfs/qemu/qemu_virtio_net.py b/vnfs/qemu/qemu_virtio_net.py index afb519c3..efeea490 100644 --- a/vnfs/qemu/qemu_virtio_net.py +++ b/vnfs/qemu/qemu_virtio_net.py @@ -36,39 +36,33 @@ class QemuVirtioNet(IVnfQemu): tasks.run_task(['sudo', 'modprobe', 'vhost_net'], self._logger, 'Loading vhost_net module...', True) - # calculate indexes of guest devices (e.g. charx, dpdkvhostuserx) - i = self._number * 2 - if1 = str(i) - if2 = str(i + 1) + # calculate index of first interface, i.e. check how many + # interfaces has been created for previous VMs, where 1st NIC + # of 1st VM has index 0 + start_index = sum(S.getValue('GUEST_NICS_NR')[:self._number]) # multi-queue values - if int(S.getValue('GUEST_NIC_QUEUES')): - queue_str = ',queues={}'.format(S.getValue('GUEST_NIC_QUEUES')) + if int(S.getValue('GUEST_NIC_QUEUES')[self._number]): + queue_str = ',queues={}'.format( + S.getValue('GUEST_NIC_QUEUES')[self._number]) mq_vector_str = ',mq=on,vectors={}'.format( - int(S.getValue('GUEST_NIC_QUEUES')) * 2 + 2) + int(S.getValue('GUEST_NIC_QUEUES')[self._number]) * 2 + 2) else: queue_str, mq_vector_str = '', '' - self._cmd += ['-netdev', - 'tap,id=' + self._net1 + queue_str + - ',script=no,downscript=no,' + - 'ifname=tap' + if1 + ',vhost=on', - '-device', - 'virtio-net-pci,mac=' + - S.getValue('GUEST_NET1_MAC')[self._number] + - ',netdev=' + self._net1 + - ',csum=off,gso=off,' + - 'guest_tso4=off,guest_tso6=off,guest_ecn=off' + - mq_vector_str, - '-netdev', - 'tap,id=' + self._net2 + queue_str + - ',script=no,downscript=no,' + - 'ifname=tap' + if2 + ',vhost=on', - '-device', - 'virtio-net-pci,mac=' + - S.getValue('GUEST_NET2_MAC')[self._number] + - ',netdev=' + self._net2 + - ',csum=off,gso=off,' + - 'guest_tso4=off,guest_tso6=off,guest_ecn=off' + - mq_vector_str, - ] + # setup requested number of interfaces + for nic in range(len(self._nics)): + index = start_index + nic + ifi = str(index) + self._cmd += ['-netdev', 'type=tap,id=' + + self._nics[nic]['device'] + queue_str + + ',script=no,downscript=no,' + + 'ifname=tap' + ifi + ',vhost=on', + '-device', + 'virtio-net-pci,mac=' + + self._nics[nic]['mac'] + ',netdev=' + + self._nics[nic]['device'] + + ',csum=off,gso=off,' + + 'guest_tso4=off,guest_tso6=off,guest_ecn=off' + + mq_vector_str, + ] diff --git a/vnfs/vnf/vnf.py b/vnfs/vnf/vnf.py index 1410a0c4..242fc502 100644 --- a/vnfs/vnf/vnf.py +++ b/vnfs/vnf/vnf.py @@ -36,6 +36,8 @@ class IVnf(tasks.Process): this call (use ``start`` method instead). """ self._number = IVnf._number_vnfs + self._logger.debug('Initializing %s. VM with index %s', + self._number + 1, self._number) IVnf._number_vnfs = IVnf._number_vnfs + 1 self._log_prefix = 'vnf_%d_cmd : ' % self._number diff --git a/vswitches/ovs_vanilla.py b/vswitches/ovs_vanilla.py index 332725e3..40ca970e 100644 --- a/vswitches/ovs_vanilla.py +++ b/vswitches/ovs_vanilla.py @@ -61,7 +61,9 @@ class OvsVanilla(IVSwitchOvs): for i in range(self._vport_id): tapx = 'tap' + str(i) tap_cmd_list = ['sudo', 'ip', 'tuntap', 'del', tapx, 'mode', 'tap'] - if int(settings.getValue('GUEST_NIC_QUEUES')): + # let's assume, that all VMs have NIC QUEUES enabled or disabled + # at the same time + if int(settings.getValue('GUEST_NIC_QUEUES')[0]): tap_cmd_list += ['multi_queue'] tasks.run_task(tap_cmd_list, self._logger, 'Deleting ' + tapx, False) self._vport_id = 0 @@ -112,13 +114,17 @@ class OvsVanilla(IVSwitchOvs): tap_name = 'tap' + str(self._vport_id) self._vport_id += 1 tap_cmd_list = ['sudo', 'ip', 'tuntap', 'del', tap_name, 'mode', 'tap'] - if int(settings.getValue('GUEST_NIC_QUEUES')): + # let's assume, that all VMs have NIC QUEUES enabled or disabled + # at the same time + if int(settings.getValue('GUEST_NIC_QUEUES')[0]): tap_cmd_list += ['multi_queue'] tasks.run_task(tap_cmd_list, self._logger, 'Creating tap device...', False) tap_cmd_list = ['sudo', 'ip', 'tuntap', 'add', tap_name, 'mode', 'tap'] - if int(settings.getValue('GUEST_NIC_QUEUES')): + # let's assume, that all VMs have NIC QUEUES enabled or disabled + # at the same time + if int(settings.getValue('GUEST_NIC_QUEUES')[0]): tap_cmd_list += ['multi_queue'] tasks.run_task(tap_cmd_list, self._logger, 'Creating tap device...', False) |