diff options
Diffstat (limited to 'docs/testing')
32 files changed, 0 insertions, 2646 deletions
diff --git a/docs/testing/developer/devguide/index.rst b/docs/testing/developer/devguide/index.rst deleted file mode 100644 index e219889..0000000 --- a/docs/testing/developer/devguide/index.rst +++ /dev/null @@ -1,8 +0,0 @@ -.. _nfvbench-releasenotes: - -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - -*************** -Developer Guide -*************** diff --git a/docs/testing/index.rst b/docs/testing/index.rst deleted file mode 100644 index b795e6b..0000000 --- a/docs/testing/index.rst +++ /dev/null @@ -1,11 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International -.. License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) Cisco Systems, Inc - -.. toctree:: - :maxdepth: 2 - - developer/devguide/index - user/configguide/index - user/userguide/index diff --git a/docs/testing/user/configguide/configguide.rst b/docs/testing/user/configguide/configguide.rst deleted file mode 100644 index f790d21..0000000 --- a/docs/testing/user/configguide/configguide.rst +++ /dev/null @@ -1,8 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International -.. License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) Cisco Systems, Inc - -******************* -Configuration Guide -******************* diff --git a/docs/testing/user/configguide/index.rst b/docs/testing/user/configguide/index.rst deleted file mode 100644 index ce3b778..0000000 --- a/docs/testing/user/configguide/index.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International -.. License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) Cisco Systems, Inc - -.. toctree:: - :maxdepth: 1 - - configguide diff --git a/docs/testing/user/userguide/_static/custom.css b/docs/testing/user/userguide/_static/custom.css deleted file mode 100644 index 6cbfde3..0000000 --- a/docs/testing/user/userguide/_static/custom.css +++ /dev/null @@ -1,4 +0,0 @@ -.wy-nav-content { - max-width: 1200px !important; -} - diff --git a/docs/testing/user/userguide/_templates/layout.html b/docs/testing/user/userguide/_templates/layout.html deleted file mode 100644 index f3387d5..0000000 --- a/docs/testing/user/userguide/_templates/layout.html +++ /dev/null @@ -1,5 +0,0 @@ -{% extends "!layout.html" %} -{% block extrahead %} - <link href="{{ pathto("_static/custom.css", True) }}" rel="stylesheet" type="text/css"> -{% endblock %} - diff --git a/docs/testing/user/userguide/advanced.rst b/docs/testing/user/userguide/advanced.rst deleted file mode 100644 index 1d2ac36..0000000 --- a/docs/testing/user/userguide/advanced.rst +++ /dev/null @@ -1,336 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - -============== -Advanced Usage -============== - -This section covers a few examples on how to run NFVbench with multiple different settings. -Below are shown the most common and useful use-cases and explained some fields from a default config file. - -How to change any NFVbench run configuration (CLI) --------------------------------------------------- -NFVbench always starts with a default configuration which can further be refined (overridden) by the user from the CLI or from REST requests. - -At first have a look at the default config: - -.. code-block:: bash - - nfvbench --show-default-config - -It is sometimes useful derive your own configuration from a copy of the default config: - -.. code-block:: bash - - nfvbench --show-default-config > nfvbench.cfg - -At this point you can edit the copy by: - -- removing any parameter that is not to be changed (since NFVbench will always load the default configuration, default values are not needed) -- edit the parameters that are to be changed changed - -A run with the new confguration can then simply be requested using the -c option and by using the actual path of the configuration file -as seen from inside the container (in this example, we assume the current directory is mapped to /tmp/nfvbench in the container): - -.. code-block:: bash - - nfvbench -c /tmp/nfvbench/nfvbench.cfg - -The same -c option also accepts any valid yaml or json string to override certain parameters without having to create a configuration file. - -NFVbench provides many configuration options as optional arguments. For example the number of flows can be specified using the --flow-count option. - -The flow count option can be specified in any of 3 ways: - -- by providing a confguration file that has the flow_count value to use (-c myconfig.yaml and myconfig.yaml contains 'flow_count: 100k') -- by passing that yaml paremeter inline (-c "flow_count: 100k") or (-c "{flow_count: 100k}") -- by using the flow count optional argument (--flow-count 100k) - -Showing the running configuration ---------------------------------- - -Because configuration parameters can be overriden, it is sometimes useful to show the final configuration (after all oevrrides are done) by using the --show-config option. -This final configuration is also called the "running" configuration. - -For example, this will only display the running configuration (without actually running anything): - -.. code-block:: bash - - nfvbench -c "{flow_count: 100k, debug: true}" --show-config - - -Connectivity and Configuration Check ------------------------------------- - -NFVbench allows to test connectivity to devices used with the selected packet path. -It runs the whole test, but without actually sending any traffic. -It is also a good way to check if everything is configured properly in the configuration file and what versions of components are used. - -To verify everything works without sending any traffic, use the --no-traffic option: - -.. code-block:: bash - - nfvbench --no-traffic - -Used parameters: - -* ``--no-traffic`` or ``-0`` : sending traffic from traffic generator is skipped - - - -Fixed Rate Run --------------- - -Fixed rate run is the most basic type of NFVbench usage. It can be used to measure the drop rate with a fixed transmission rate of packets. - -This example shows how to run the PVP packet path (which is the default packet path) with multiple different settings: - -.. code-block:: bash - - nfvbench -c nfvbench.cfg --no-cleanup --rate 100000pps --duration 30 --interval 15 --json results.json - -Used parameters: - -* ``-c nfvbench.cfg`` : path to the config file -* ``--no-cleanup`` : resources (networks, VMs, attached ports) are not deleted after test is finished -* ``--rate 100000pps`` : defines rate of packets sent by traffic generator -* ``--duration 30`` : specifies how long should traffic be running in seconds -* ``--interval 15`` : stats are checked and shown periodically (in seconds) in this interval when traffic is flowing -* ``--json results.json`` : collected data are stored in this file after run is finished - -.. note:: It is your responsibility to clean up resources if needed when ``--no-cleanup`` parameter is used. You can use the nfvbench_cleanup helper script for that purpose. - -The ``--json`` parameter makes it easy to store NFVbench results. The --show-summary (or -ss) option can be used to display the results in a json results file in a text tabular format: - -.. code-block:: bash - - nfvbench --show-summary results.json - - -This example shows how to specify a different packet path: - -.. code-block:: bash - - nfvbench -c nfvbench.cfg --rate 1Mbps --inter-node --service-chain PVVP - -Used parameters: - -* ``-c nfvbench.cfg`` : path to the config file -* ``--rate 1Mbps`` : defines rate of packets sent by traffic generator -* ``--inter-node`` : VMs are created on different compute nodes, works only with PVVP flow -* ``--service-chain PVVP`` or ``-sc PVVP`` : specifies the type of service chain (or packet path) to use - -.. note:: When parameter ``--inter-node`` is not used or there aren't enough compute nodes, VMs are on the same compute node. - - -Rate Units -^^^^^^^^^^ - -Parameter ``--rate`` accepts different types of values: - -* packets per second (pps, kpps, mpps), e.g. ``1000pps`` or ``10kpps`` -* load percentage (%), e.g. ``50%`` -* bits per second (bps, kbps, Mbps, Gbps), e.g. ``1Gbps``, ``1000bps`` -* NDR/PDR (ndr, pdr, ndr_pdr), e.g. ``ndr_pdr`` - -NDR/PDR is the default rate when not specified. - -NDR and PDR ------------ - -The NDR and PDR test is used to determine the maximum throughput performance of the system under test -following guidelines defined in RFC-2544: - -* NDR (No Drop Rate): maximum packet rate sent without dropping any packet -* PDR (Partial Drop Rate): maximum packet rate sent while allowing a given maximum drop rate - -The NDR search can also be relaxed to allow some very small amount of drop rate (lower than the PDR maximum drop rate). -NFVbench will measure the NDR and PDR values by driving the traffic generator through multiple iterations -at different transmission rates using a binary search algorithm. - -The configuration file contains section where settings for NDR/PDR can be set. - -.. code-block:: bash - - # NDR/PDR configuration - measurement: - # Drop rates represent the ratio of dropped packet to the total number of packets sent. - # Values provided here are percentages. A value of 0.01 means that at most 0.01% of all - # packets sent are dropped (or 1 packet every 10,000 packets sent) - - # No Drop Rate; Default to 0.001% - NDR: 0.001 - # Partial Drop Rate; NDR should always be less than PDR - PDR: 0.1 - # The accuracy of NDR and PDR load percentiles; The actual load percentile that match NDR - # or PDR should be within `load_epsilon` difference than the one calculated. - load_epsilon: 0.1 - -Because NDR/PDR is the default ``--rate`` value, it is possible to run NFVbench simply like this: - -.. code-block:: bash - - nfvbench -c nfvbench.cfg - -Other possible run options: - -.. code-block:: bash - - nfvbench -c nfvbench.cfg --duration 120 --json results.json - -Used parameters: - -* ``-c nfvbench.cfg`` : path to the config file -* ``--duration 120`` : specifies how long should be traffic running in each iteration -* ``--json results.json`` : collected data are stored in this file after run is finished - - -Multichain ----------- - -NFVbench allows to run multiple chains at the same time. For example it is possible to stage the PVP service chain N-times, -where N can be as much as your compute power can scale. With N = 10, NFVbench will spawn 10 VMs as a part of 10 simultaneous PVP chains. - -The number of chains is specified by ``--service-chain-count`` or ``-scc`` flag with a default value of 1. -For example to run NFVbench with 3 PVP chains: - -.. code-block:: bash - - nfvbench -c nfvbench.cfg --rate 10000pps -scc 3 - -It is not necessary to specify the service chain type (-sc) because PVP is set as default. The PVP service chains will have 3 VMs in 3 chains with this configuration. -If ``-sc PVVP`` is specified instead, there would be 6 VMs in 3 chains as this service chain has 2 VMs per chain. -Both **single run** or **NDR/PDR** can be run as multichain. Runnin multichain is a scenario closer to a real life situation than runs with a single chain. - - -Multiflow ---------- - -NFVbench always generates L3 packets from the traffic generator but allows the user to specify how many flows to generate. -A flow is identified by a unique src/dest MAC IP and port tuple that is sent by the traffic generator. Flows are -generated by ranging the IP adresses but using a small fixed number of MAC addresses. - -The number of flows will be spread roughly even between chains when more than 1 chain is being tested. -For example, for 11 flows and 3 chains, number of flows that will run for each chain will be 3, 4, and 4 flows respectively. - -The number of flows is specified by ``--flow-count`` or ``-fc`` flag, the default value is 2 (1 flow in each direction). -To run NFVbench with 3 chains and 100 flows, use the following command: - -.. code-block:: bash - - nfvbench -c nfvbench.cfg --rate 10000pps -scc 3 -fc 100 - -Note that from a vswitch point of view, the -number of flows seen will be higher as it will be at least 4 times the number of flows sent by the traffic generator -(add flow to VM and flow from VM). - -IP addresses generated can be controlled with the following NFVbench configuration options: - -.. code-block:: bash - - ip_addrs: ['10.0.0.0/8', '20.0.0.0/8'] - ip_addrs_step: 0.0.0.1 - tg_gateway_ip_addrs: ['1.1.0.100', '2.2.0.100'] - tg_gateway_ip_addrs_step: 0.0.0.1 - gateway_ip_addrs: ['1.1.0.2', '2.2.0.2'] - gateway_ip_addrs_step: 0.0.0.1 - -``ip_addrs`` are the start of the 2 ip address ranges used by the traffic generators as the packets source and destination packets -where each range is associated to virtual devices simulated behind 1 physical interface of the traffic generator. -These can also be written in CIDR notation to represent the subnet. - -``tg_gateway_ip_addrs`` are the traffic generator gateway (virtual) ip addresses, all traffic to/from the virtual devices go through them. - -``gateway_ip_addrs`` are the 2 gateway ip address ranges of the VMs used in the external chains. They are only used with external chains and must correspond to their public IP address. - -The corresponding ``step`` is used for ranging the IP addresses from the `ip_addrs``, ``tg_gateway_ip_addrs`` and ``gateway_ip_addrs`` base addresses. -0.0.0.1 is the default step for all IP ranges. In ``ip_addrs``, 'random' can be configured which tells NFVBench to generate random src/dst IP pairs in the traffic stream. - - -Traffic Configuration via CLI ------------------------------ - -While traffic configuration can be modified using the configuration file, it can be inconvenient to have to change the configuration file everytime -you need to change a traffic configuration option. Traffic configuration options can be overridden with a few CLI options. - -Here is an example of configuring traffic via CLI: - -.. code-block:: bash - - nfvbench --rate 10kpps --service-chain-count 2 -fs 64 -fs IMIX -fs 1518 --unidir - -This command will run NFVbench with a unidirectional flow for three packet sizes 64B, IMIX, and 1518B. - -Used parameters: - -* ``--rate 10kpps`` : defines rate of packets sent by traffic generator (total TX rate) -* ``-scc 2`` or ``--service-chain-count 2`` : specifies number of parallel chains of given flow to run (default to 1) -* ``-fs 64`` or ``--frame-size 64``: add the specified frame size to the list of frame sizes to run -* ``--unidir`` : run traffic with unidirectional flow (default to bidirectional flow) - - -MAC Addresses -------------- - -NFVbench will dicover the MAC addresses to use for generated frames using: -- either OpenStack discovery (find the MAC of an existing VM) in the case of PVP and PVVP service chains -- or using dynamic ARP discovery (find MAC from IP) in the case of external chains. - -Status and Cleanup of NFVbench Resources ----------------------------------------- - -The --status option will display the status of NFVbench and list any NFVbench resources. You need to pass the OpenStack RC -file in order to connect to OpenStack. - -.. code-block:: none - - # nfvbench --status -r /tmp/nfvbench/openrc - 2018-04-09 17:05:48,682 INFO Version: 1.3.2.dev1 - 2018-04-09 17:05:48,683 INFO Status: idle - 2018-04-09 17:05:48,757 INFO Discovering instances nfvbench-loop-vm... - 2018-04-09 17:05:49,252 INFO Discovering flavor nfvbench.medium... - 2018-04-09 17:05:49,281 INFO Discovering networks... - 2018-04-09 17:05:49,365 INFO No matching NFVbench resources found - # - -The Status can be either "idle" or "busy (run pending)". - -The --cleanup option will first discover resources created by NFVbench and prompt if you want to proceed with cleaning them up. -Example of run: - -.. code-block:: none - - # nfvbench --cleanup -r /tmp/nfvbench/openrc - 2018-04-09 16:58:00,204 INFO Version: 1.3.2.dev1 - 2018-04-09 16:58:00,205 INFO Status: idle - 2018-04-09 16:58:00,279 INFO Discovering instances nfvbench-loop-vm... - 2018-04-09 16:58:00,829 INFO Discovering flavor nfvbench.medium... - 2018-04-09 16:58:00,876 INFO Discovering networks... - 2018-04-09 16:58:00,960 INFO Discovering ports... - 2018-04-09 16:58:01,012 INFO Discovered 6 NFVbench resources: - +----------+-------------------+--------------------------------------+ - | Type | Name | UUID | - |----------+-------------------+--------------------------------------| - | Instance | nfvbench-loop-vm0 | b039b858-777e-467e-99fb-362f856f4a94 | - | Flavor | nfvbench.medium | a027003c-ad86-4f24-b676-2b05bb06adc0 | - | Network | nfvbench-net0 | bca8d183-538e-4965-880e-fd92d48bfe0d | - | Network | nfvbench-net1 | c582a201-8279-4309-8084-7edd6511092c | - | Port | | 67740862-80ac-4371-b04e-58a0b0f05085 | - | Port | | b5db95b9-e419-4725-951a-9a8f7841e66a | - +----------+-------------------+--------------------------------------+ - 2018-04-09 16:58:01,013 INFO NFVbench will delete all resources shown... - Are you sure? (y/n) y - 2018-04-09 16:58:01,865 INFO Deleting instance nfvbench-loop-vm0... - 2018-04-09 16:58:02,058 INFO Waiting for 1 instances to be fully deleted... - 2018-04-09 16:58:02,182 INFO 1 yet to be deleted by Nova, retries left=6... - 2018-04-09 16:58:04,506 INFO 1 yet to be deleted by Nova, retries left=5... - 2018-04-09 16:58:06,636 INFO 1 yet to be deleted by Nova, retries left=4... - 2018-04-09 16:58:08,701 INFO Deleting flavor nfvbench.medium... - 2018-04-09 16:58:08,729 INFO Deleting port 67740862-80ac-4371-b04e-58a0b0f05085... - 2018-04-09 16:58:09,102 INFO Deleting port b5db95b9-e419-4725-951a-9a8f7841e66a... - 2018-04-09 16:58:09,620 INFO Deleting network nfvbench-net0... - 2018-04-09 16:58:10,357 INFO Deleting network nfvbench-net1... - # - -The --force-cleanup option will do the same but without prompting for confirmation. diff --git a/docs/testing/user/userguide/conf.py b/docs/testing/user/userguide/conf.py deleted file mode 100644 index 5846b00..0000000 --- a/docs/testing/user/userguide/conf.py +++ /dev/null @@ -1,358 +0,0 @@ -# Copyright 2017 Cisco Systems, Inc. All rights reserved. -# -# 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. -# -# NFVBench documentation build configuration file, created by -# sphinx-quickstart on Thu Sep 29 14:25:18 2016. -# -# This file is execfile()d with the current directory set to its -# containing dir. -# -# Note that not all possible configuration values are present in this -# autogenerated file. -# -# All configuration values have a default; values that are commented out -# serve to show the default. - -# If extensions (or modules to document with autodoc) are in another directory, -# add these directories to sys.path here. If the directory is relative to the -# documentation root, use os.path.abspath to make it absolute, like shown here. -# - - - -# import os -# import sys -# sys.path.insert(0, os.path.abspath('.')) -import os -from pbr import version as pbr_ver -import sys - -sys.path.insert(0, os.path.abspath('../..')) - -# -- General configuration ------------------------------------------------ - -# If your documentation needs a minimal Sphinx version, state it here. -# -# needs_sphinx = '1.0' - -# Add any Sphinx extension module names here, as strings. They can be -# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom -# ones. -extensions = [] - -# Add any paths that contain templates here, relative to this directory. -templates_path = ['_templates'] - -# The suffix(es) of source filenames. -# You can specify multiple suffix as a list of string: -# -# source_suffix = ['.rst', '.md'] -source_suffix = '.rst' - -# The encoding of source files. -# -# source_encoding = 'utf-8-sig' - -# The master toctree document. -master_doc = 'index' - -# General information about the project. -project = u'NFVBench' -copyright = u'2016 Cisco Systems, Inc.' -author = u'Cisco Systems, Inc.' - -# The version info for the project you're documenting, acts as replacement for -# |version| and |release|, also used in various other places throughout the -# built documents. -# -# The short X.Y version. -version = pbr_ver.VersionInfo(project).version_string() -# The full version, including alpha/beta/rc tags. -release = pbr_ver.VersionInfo(project).version_string_with_vcs() - -# The language for content autogenerated by Sphinx. Refer to documentation -# for a list of supported languages. -# -# This is also used if you do content translation via gettext catalogs. -# Usually you set "language" from the command line for these cases. -language = None - -# There are two options for replacing |today|: either, you set today to some -# non-false value, then it is used: -# -# today = '' -# -# Else, today_fmt is used as the format for a strftime call. -# -# today_fmt = '%B %d, %Y' - -# List of patterns, relative to source directory, that match files and -# directories to ignore when looking for source files. -# This patterns also effect to html_static_path and html_extra_path -exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store'] - -# The reST default role (used for this markup: `text`) to use for all -# documents. -# -# default_role = None - -# If true, '()' will be appended to :func: etc. cross-reference text. -# -# add_function_parentheses = True - -# If true, the current module name will be prepended to all description -# unit titles (such as .. function::). -# -# add_module_names = True - -# If true, sectionauthor and moduleauthor directives will be shown in the -# output. They are ignored by default. -# -# show_authors = False - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'sphinx' - -# A list of ignored prefixes for module index sorting. -# modindex_common_prefix = [] - -# If true, keep warnings as "system message" paragraphs in the built documents. -# keep_warnings = False - -# If true, `todo` and `todoList` produce output, else they produce nothing. -todo_include_todos = False - -# -- Options for HTML output ---------------------------------------------- - -# The theme to use for HTML and HTML Help pages. See the documentation for -# a list of builtin themes. -# -# html_theme = 'haiku' -html_theme = 'sphinx_rtd_theme' - -# Theme options are theme-specific and customize the look and feel of a theme -# further. For a list of options available for each theme, see the -# documentation. -# -html_theme_options = {} - -# Add any paths that contain custom themes here, relative to this directory. -# html_theme_path = [] - -# The name for this set of Sphinx documents. -# "<project> v<release> documentation" by default. -# -# html_title = u'NFVBench vdev117' - -# A shorter title for the navigation bar. Default is the same as html_title. -# -html_short_title = 'nfvbench' - -# The name of an image file (relative to this directory) to place at the topß -# of the sidebar. -# -# html_logo = None - -# The name of an image file (relative to this directory) to use as a favicon of -# the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 -# pixels large. -# -# html_favicon = None - -# Add any paths that contain custom static files (such as style sheets) here, -# relative to this directory. They are copied after the builtin static files, -# so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['_static'] - -# Add any extra paths that contain custom files (such as robots.txt or -# .htaccess) here, relative to this directory. These files are copied -# directly to the root of the documentation. -# -# html_extra_path = [] - -# If not None, a 'Last updated on:' timestamp is inserted at every page -# bottom, using the given strftime format. -# The empty string is equivalent to '%b %d, %Y'. -# -# html_last_updated_fmt = None - -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -# -html_use_smartypants = False - -# Custom sidebar templates, maps document names to template names. -# -# html_sidebars = {} - -# Additional templates that should be rendered to pages, maps page names to -# template names. -# -# html_additional_pages = {} - -# If false, no module index is generated. -# -# html_domain_indices = True - -# If false, no index is generated. -# -# html_use_index = True - -# If true, the index is split into individual pages for each letter. -# -# html_split_index = False - -# If true, links to the reST sources are added to the pages. -# -# html_show_sourcelink = True - -# If true, "Created using Sphinx" is shown in the HTML footer. Default is True. -# -# html_show_sphinx = True - -# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. -# -# html_show_copyright = True - -# If true, an OpenSearch description file will be output, and all pages will -# contain a <link> tag referring to it. The value of this option must be the -# base URL from which the finished HTML is served. -# -# html_use_opensearch = '' - -# This is the file name suffix for HTML files (e.g. ".xhtml"). -# html_file_suffix = None - -# Language to be used for generating the HTML full-text search index. -# Sphinx supports the following languages: -# 'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja' -# 'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr', 'zh' -# -# html_search_language = 'en' - -# A dictionary with options for the search language support, empty by default. -# 'ja' uses this config value. -# 'zh' user can custom change `jieba` dictionary path. -# -# html_search_options = {'type': 'default'} - -# The name of a javascript file (relative to the configuration directory) that -# implements a search results scorer. If empty, the default will be used. -# -# html_search_scorer = 'scorer.js' - -# Output file base name for HTML help builder. -htmlhelp_basename = 'NFVBenchdoc' - -# -- Options for LaTeX output --------------------------------------------- - -latex_elements = { - # The paper size ('letterpaper' or 'a4paper'). - # - # 'papersize': 'letterpaper', - - # The font size ('10pt', '11pt' or '12pt'). - # - # 'pointsize': '10pt', - - # Additional stuff for the LaTeX preamble. - # - # 'preamble': '', - - # Latex figure (float) alignment - # - # 'figure_align': 'htbp', -} - -# Grouping the document tree into LaTeX files. List of tuples -# (source start file, target name, title, -# author, documentclass [howto, manual, or own class]). -latex_documents = [ - (master_doc, 'NFVBench.tex', u'NFVBench Documentation', - u'Alec Hothan, Stefano Suryanto, Jan Balaz', 'manual'), -] - -# The name of an image file (relative to this directory) to place at the top of -# the title page. -# -# latex_logo = None - -# For "manual" documents, if this is true, then toplevel headings are parts, -# not chapters. -# -# latex_use_parts = False - -# If true, show page references after internal links. -# -# latex_show_pagerefs = False - -# If true, show URL addresses after external links. -# -# latex_show_urls = False - -# Documents to append as an appendix to all manuals. -# -# latex_appendices = [] - -# It false, will not define \strong, \code, itleref, \crossref ... but only -# \sphinxstrong, ..., \sphinxtitleref, ... To help avoid clash with user added -# packages. -# -# latex_keep_old_macro_names = True - -# If false, no module index is generated. -# -# latex_domain_indices = True - - -# -- Options for manual page output --------------------------------------- - -# One entry per manual page. List of tuples -# (source start file, name, description, authors, manual section). -man_pages = [ - (master_doc, 'nfvbench', u'NFVBench Documentation', - [author], 1) -] - -# If true, show URL addresses after external links. -# -# man_show_urls = False - - -# -- Options for Texinfo output ------------------------------------------- - -# Grouping the document tree into Texinfo files. List of tuples -# (source start file, target name, title, author, -# dir menu entry, description, category) -texinfo_documents = [ - (master_doc, 'NFVBench', u'NFVBench Documentation', - author, 'NFVBench', 'One line description of project.', - 'Miscellaneous'), -] - -# Documents to append as an appendix to all manuals. -# -# texinfo_appendices = [] - -# If false, no module index is generated. -# -# texinfo_domain_indices = True - -# How to display URL addresses: 'footnote', 'no', or 'inline'. -# -# texinfo_show_urls = 'footnote' - -# If true, do not generate a @detailmenu in the "Top" node's menu. -# -# texinfo_no_detailmenu = False diff --git a/docs/testing/user/userguide/examples.rst b/docs/testing/user/userguide/examples.rst deleted file mode 100644 index fd6be5c..0000000 --- a/docs/testing/user/userguide/examples.rst +++ /dev/null @@ -1,134 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - -Example of Results -****************** -Example run for fixed rate - -.. code-block:: bash - - nfvbench -c /nfvbench/nfvbenchconfig.json --rate 1% - -.. code-block:: bash - - ========== NFVBench Summary ========== - Date: 2017-09-21 23:57:44 - NFVBench version 1.0.9 - Openstack Neutron: - vSwitch: BASIC - Encapsulation: BASIC - Benchmarks: - > Networks: - > Components: - > TOR: - Type: None - > Traffic Generator: - Profile: trex-local - Tool: TRex - > Versions: - > TOR: - > Traffic Generator: - build_date: Aug 30 2017 - version: v2.29 - built_by: hhaim - build_time: 16:43:55 - > Service chain: - > PVP: - > Traffic: - Profile: traffic_profile_64B - Bidirectional: True - Flow count: 10000 - Service chains count: 1 - Compute nodes: [] - - Run Summary: - - +-----------------+-------------+----------------------+----------------------+----------------------+ - | L2 Frame Size | Drop Rate | Avg Latency (usec) | Min Latency (usec) | Max Latency (usec) | - +=================+=============+======================+======================+======================+ - | 64 | 0.0000% | 53 | 20 | 211 | - +-----------------+-------------+----------------------+----------------------+----------------------+ - - - L2 frame size: 64 - Chain analysis duration: 60.076 seconds - - Run Config: - - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - | Direction | Requested TX Rate (bps) | Actual TX Rate (bps) | RX Rate (bps) | Requested TX Rate (pps) | Actual TX Rate (pps) | RX Rate (pps) | - +=============+===========================+========================+=================+===========================+========================+=================+ - | Forward | 100.0000 Mbps | 95.4546 Mbps | 95.4546 Mbps | 148,809 pps | 142,045 pps | 142,045 pps | - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - | Reverse | 100.0000 Mbps | 95.4546 Mbps | 95.4546 Mbps | 148,809 pps | 142,045 pps | 142,045 pps | - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - | Total | 200.0000 Mbps | 190.9091 Mbps | 190.9091 Mbps | 297,618 pps | 284,090 pps | 284,090 pps | - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - - Chain Analysis: - - +-------------------+----------+-----------------+---------------+---------------+-----------------+---------------+---------------+ - | Interface | Device | Packets (fwd) | Drops (fwd) | Drop% (fwd) | Packets (rev) | Drops (rev) | Drop% (rev) | - +===================+==========+=================+===============+===============+=================+===============+===============+ - | traffic-generator | trex | 8,522,729 | | | 8,522,729 | 0 | 0.0000% | - +-------------------+----------+-----------------+---------------+---------------+-----------------+---------------+---------------+ - | traffic-generator | trex | 8,522,729 | 0 | 0.0000% | 8,522,729 | | | - +-------------------+----------+-----------------+---------------+---------------+-----------------+---------------+---------------+ - -Example run for NDR/PDR with package size 1518B - -.. code-block:: bash - - nfvbench -c /nfvbench/nfvbenchconfig.json -fs 1518 - -.. code-block:: bash - - ========== NFVBench Summary ========== - Date: 2017-09-22 00:02:07 - NFVBench version 1.0.9 - Openstack Neutron: - vSwitch: BASIC - Encapsulation: BASIC - Benchmarks: - > Networks: - > Components: - > TOR: - Type: None - > Traffic Generator: - Profile: trex-local - Tool: TRex - > Versions: - > TOR: - > Traffic Generator: - build_date: Aug 30 2017 - version: v2.29 - built_by: hhaim - build_time: 16:43:55 - > Measurement Parameters: - NDR: 0.001 - PDR: 0.1 - > Service chain: - > PVP: - > Traffic: - Profile: custom_traffic_profile - Bidirectional: True - Flow count: 10000 - Service chains count: 1 - Compute nodes: [] - - Run Summary: - - +-----+-----------------+------------------+------------------+-----------------+----------------------+----------------------+----------------------+ - | - | L2 Frame Size | Rate (fwd+rev) | Rate (fwd+rev) | Avg Drop Rate | Avg Latency (usec) | Min Latency (usec) | Max Latency (usec) | - +=====+=================+==================+==================+=================+======================+======================+======================+ - | NDR | 1518 | 19.9805 Gbps | 1,623,900 pps | 0.0001% | 342 | 30 | 704 | - +-----+-----------------+------------------+------------------+-----------------+----------------------+----------------------+----------------------+ - | PDR | 1518 | 20.0000 Gbps | 1,625,486 pps | 0.0022% | 469 | 40 | 1,266 | - +-----+-----------------+------------------+------------------+-----------------+----------------------+----------------------+----------------------+ - - - L2 frame size: 1518 - Chain analysis duration: 660.442 seconds - NDR search duration: 660 seconds - PDR search duration: 0 seconds diff --git a/docs/testing/user/userguide/extchains.rst b/docs/testing/user/userguide/extchains.rst deleted file mode 100644 index f7c0e51..0000000 --- a/docs/testing/user/userguide/extchains.rst +++ /dev/null @@ -1,77 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - -=============== -External Chains -=============== - -NFVbench can measure the performance of 1 or more L3 service chains that are setup externally using OpenStack or without OpenStack. -Instead of being setup by NFVbench, the complete environment (VNFs and networks) must be setup prior to running NFVbench. - -Each external chain is made of 1 or more VNFs and has exactly 2 edge network interfaces (left and right network interfaces) -that are connected to 2 edge networks (left and right networks). -The 2 edge networks for each chain can either be shared across all chains or can be independent. - -The internal composition of a multi-VNF service chain can be arbitrary (usually linear) as far as NFVbench is concerned, -the only requirement is that the service chain can route L3 packets properly between the left and right networks. - -The network topology of the service chains is defined by the "service_chain_shared_net" option in the -NFVbench configuration file. - - -Shared Edge Networks --------------------- - -This option is defined when "service_chain_shared_net" is set to true. -All chains must share the same 2 edge networks and the VNF gateway IP addresses on each edge -must all belong to the same subnet. - -.. image:: images/nfvbench-ext-shared.png - -The main advantage of this mode is that only 2 network segments are needed to support an arbitrary number of chains. - - -Multi-VLAN Edge Networks ------------------------- - -This option is defined when "service_chain_shared_net" is set to false (default). -Each chain has its own dedicated left and right network and there is no inter-chain constraint -on the VNF IP addresses since they all belong to different network segments. - -.. image:: images/nfvbench-ext-multi-vlans.png - -The advantage of this mode is that the configuration of the VNFs can be made identical (same -gateway IP addresses, same static routes). -However this mode requires 2 network segments per chain. - - -Detailed Example ----------------- -To run NFVbench on an external service chains using shared edge networks: - -- tell NFVbench to use external service chain by adding "-sc EXT" or "--service-chain EXT" to NFVbench CLI options -- specify the number of external chains using the "-scc" option (defaults to 1 chain) -- if OpenStack is used: - - specify the name of the 2 edge networks in "external_networks" in the NFVbench configuration file - - The two networks specified have to exist in Neutron ('napa' and 'marin' in the diagram below) -- if OpenStack is not used: - - specify the VLAN id to use for the 2 edge networks in "vlans" in the NFVbench configuration file -- specify the VNF gateway IPs for the external service chains (1.1.0.2 and 2.2.0.2) -- specify the traffic generator gateway IPs for the external service chains (1.1.0.102 and 2.2.0.102 in diagram below) -- specify the packet source and destination IPs for the virtual devices that are simulated (10.0.0.0/8 and 20.0.0.0/8) - -.. image:: images/extchain-config.png - -L3 routing must be enabled in the VNF and configured to: - -- reply to ARP requests to its public IP addresses on both left and right networks -- route packets from each set of remote devices toward the appropriate dest gateway IP in the traffic generator using 2 static routes (as illustrated in the diagram) - -Upon start, NFVbench will: -- first retrieve the properties of the left and right networks using Neutron APIs, -- extract the underlying network ID (typically VLAN segmentation ID), -- generate packets with the proper VLAN ID and measure traffic. - -Note that in the case of multiple chains, all chains end interfaces must be connected to the same two left and right networks. -The traffic will be load balanced across the corresponding gateway IP of these external service chains. diff --git a/docs/testing/user/userguide/faq.rst b/docs/testing/user/userguide/faq.rst deleted file mode 100644 index 9da2e90..0000000 --- a/docs/testing/user/userguide/faq.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - -Frequently Asked Questions -************************** - -General Questions -================= - -Can NFVbench be used without OpenStack --------------------------------------- -Yes. This can be done using the EXT chain mode, with or without ARP -(depending on whether your systen under test can do routing) and by setting the openrc_file -property to empty in the NFVbench configuration. - -Can NFVbench be used with a different traffic generator than TRex? ------------------------------------------------------------------- -This is possible but requires developing a new python class to manage the new traffic generator interface. - -Can I connect Trex directly to my compute node? ------------------------------------------------ -Yes. - -Can I drive NFVbench using a REST interface? --------------------------------------------- -NFVbench can run in server mode and accept HTTP or WebSocket/SocketIO events to run any type of measurement (fixed rate run or NDR_PDR run) -with any run configuration. - -Can I run NFVbench on a Cisco UCS-B series blade? -------------------------------------------------- -Yes provided your UCS-B series server has a Cisco VIC 1340 (with a recent firmware version). -TRex will require VIC firmware version 3.1(2) or higher for blade servers (which supports more filtering capabilities). -In this setting, the 2 physical interfaces for data plane traffic are simply hooked to the UCS-B fabric interconnect (no need to connect to a switch). - -Troubleshooting -=============== - -TrafficClientException: End-to-end connectivity cannot be ensured ------------------------------------------------------------------- -Prior to running a benchmark, NFVbench will make sure that traffic is passing in the service chain by sending a small flow of packets in each direction and verifying that they are received back at the other end. -This exception means that NFVbench cannot pass any traffic in the service chain. - -The most common issues that prevent traffic from passing are: -- incorrect wiring of the NFVbench/TRex interfaces -- incorrect vlan_tagging setting in the NFVbench configuration, this needs to match how the NFVbench ports on the switch are configured (trunk or access port) - - - if the switch port is configured as access port, you must disable vlan_tagging in the NFVbench configuration - - of the switch port is configured as trunk (recommended method), you must enable it diff --git a/docs/testing/user/userguide/fluentd.rst b/docs/testing/user/userguide/fluentd.rst deleted file mode 100644 index e1ff37f..0000000 --- a/docs/testing/user/userguide/fluentd.rst +++ /dev/null @@ -1,194 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - -NFVbench Fluentd Integration -============================================ - -NFVbench has an optional fluentd integration to save logs and results. - -Configuring Fluentd to receive NFVbench logs and results --------------------------------------------------------- - -The following configurations should be added to Fluentd configuration file to enable logs or results. - -To receive logs, and forward to a storage server: - -In the example below nfvbench is the tag name for logs (which should be matched with logging_tag -under NFVbench configuration), and storage backend is elasticsearch which is -running at localhost:9200. - - -.. code-block:: bash - - <match nfvbench.**> - @type copy - <store> - @type elasticsearch - host localhost - port 9200 - logstash_format true - logstash_prefix nfvbench - utc_index false - flush_interval 15s - </store> - </match> - -To receive results, and forward to a storage server: - -In the example below resultnfvbench is the tag name for results (which should be matched with result_tag -under NFVbench configuration), and storage backend is elasticsearch which is -running at localhost:9200. - -.. code-block:: bash - - <match resultnfvbench.**> - @type copy - <store> - @type elasticsearch - host localhost - port 9200 - logstash_format true - logstash_prefix resultnfvbench - utc_index false - flush_interval 15s - </store> - </match> - -Configuring NFVbench to connect Fluentd ---------------------------------------- - -To configure NFVbench to connect Fluentd, fill following configuration parameters in the -configuration file - -+------------------------------------------------------+------------------------------------------------------+ -| Configuration | Description | -+======================================================+======================================================+ -| logging_tag | Tag for NFVbench logs, it should be the same tag | -| | defined in Fluentd configuration | -+------------------------------------------------------+------------------------------------------------------+ -| result_tag | Tag for NFVbench results, it should be the same tag | -| | defined in Fluentd configuration | -+------------------------------------------------------+------------------------------------------------------+ -| ip | ip address of Fluentd server | -+------------------------------------------------------+------------------------------------------------------+ -| port | port number of Fluentd serverd | -+------------------------------------------------------+------------------------------------------------------+ - -An example of configuration for Fluentd working at 127.0.0.1:24224 and tags for logging is nfvbench -and result is resultnfvbench - -.. code-block:: bash - - fluentd: - # by default (logging_tag is empty) nfvbench log messages are not sent to fluentd - # to enable logging to fluents, specify a valid fluentd tag name to be used for the - # log records - logging_tag: nfvbench - - # by default (result_tag is empty) nfvbench results are not sent to fluentd - # to enable sending nfvbench results to fluentd, specify a valid fluentd tag name - # to be used for the results records, which is different than logging_tag - result_tag: resultnfvbench - - # IP address of the server, defaults to loopback - ip: 127.0.0.1 - - # port # to use, by default, use the default fluentd forward port - port: 24224 - -Example of logs and results ---------------------------- - -An example of log obtained from fluentd by elasticsearch: - -.. code-block:: bash - - { - "_index": "nfvbench-2017.10.17", - "_type": "fluentd", - "_id": "AV8rhnCjTgGF_dX8DiKK", - "_version": 1, - "_score": 3, - "_source": { - "loglevel": "INFO", - "message": "Service chain 'PVP' run completed.", - "@timestamp": "2017-10-17T18:09:09.516897+0000", - "runlogdate": "2017-10-17T18:08:51.851253+0000" - }, - "fields": { - "@timestamp": [ - 1508263749516 - ] - } - } - - - -For each packet size and rate a result record is sent. Users can label those results by passing ---user-label parameter to NFVbench run - -.. code-block::bash - - nfvbench --rate 1% --user-label nfvbench-label - -And the results of this command obtained from fluentd by elasticsearch: - -.. code-block:: bash - - { - "_index": "resultnfvbench-2017.10.17", - "_type": "fluentd", - "_id": "AV8rjYlbTgGF_dX8Drl1", - "_version": 1, - "_score": null, - "_source": { - "compute_nodes": [ - "nova:compute-3" - ], - "total_orig_rate_bps": 200000000, - "@timestamp": "2017-10-17T18:16:43.755240+0000", - "frame_size": "64", - "forward_orig_rate_pps": 148809, - "flow_count": 10000, - "avg_delay_usec": 6271, - "total_tx_rate_pps": 283169, - "total_tx_rate_bps": 190289668, - "forward_tx_rate_bps": 95143832, - "reverse_tx_rate_bps": 95145836, - "forward_tx_rate_pps": 141583, - "chain_analysis_duration": "60.091", - "service_chain": "PVP", - "version": "1.0.10.dev1", - "runlogdate": "2017-10-17T18:10:12.134260+0000", - "Encapsulation": "VLAN", - "user_label": "nfvbench-label", - "min_delay_usec": 70, - "profile": "traffic_profile_64B", - "reverse_rx_rate_pps": 68479, - "reverse_rx_rate_bps": 46018044, - "reverse_orig_rate_pps": 148809, - "total_rx_rate_bps": 92030085, - "drop_rate_percent": 51.6368455626846, - "forward_orig_rate_bps": 100000000, - "bidirectional": true, - "vSwitch": "OPENVSWITCH", - "sc_count": 1, - "total_orig_rate_pps": 297618, - "type": "single_run", - "reverse_orig_rate_bps": 100000000, - "total_rx_rate_pps": 136949, - "max_delay_usec": 106850, - "forward_rx_rate_pps": 68470, - "forward_rx_rate_bps": 46012041, - "reverse_tx_rate_pps": 141586 - }, - "fields": { - "@timestamp": [ - 1508264203755 - ] - }, - "sort": [ - 1508264203755 - ] - } diff --git a/docs/testing/user/userguide/hw_requirements.rst b/docs/testing/user/userguide/hw_requirements.rst deleted file mode 100644 index 4fc6e21..0000000 --- a/docs/testing/user/userguide/hw_requirements.rst +++ /dev/null @@ -1,70 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - -Requirements for running NFVbench -================================= - -.. _requirements: - -Hardware Requirements ---------------------- -To run NFVbench you need the following hardware: -- a Linux server -- a DPDK compatible NIC with at least 2 ports (preferably 10Gbps or higher) -- 2 ethernet cables between the NIC and the OpenStack pod under test (usually through a top of rack switch) - -The DPDK-compliant NIC must be one supported by the TRex traffic generator (such as Intel X710, refer to the `Trex Installation Guide <https://trex-tgn.cisco.com/trex/doc/trex_manual.html#_download_and_installation>`_ for a complete list of supported NIC) - -To run the TRex traffic generator (that is bundled with NFVbench) you will need to wire 2 physical interfaces of the NIC to the TOR switch(es): - - if you have only 1 TOR, wire both interfaces to that same TOR - - 1 interface to each TOR if you have 2 TORs and want to use bonded links to your compute nodes - -.. image:: images/nfvbench-trex-setup.png - - -Switch Configuration --------------------- -The 2 corresponding ports on the switch(es) facing the Trex ports on the Linux server should be configured in trunk mode (NFVbench will instruct TRex to insert the appropriate vlan tag). - -Using a TOR switch is more representative of a real deployment and allows to measure packet flows on any compute node in the rack without rewiring and includes the overhead of the TOR switch. - -Although not the primary targeted use case, NFVbench could also support the direct wiring of the traffic generator to -a compute node without a switch. - -Software Requirements ---------------------- - -You need Docker to be installed on the Linux server. - -TRex uses the DPDK interface to interact with the DPDK compatible NIC for sending and receiving frames. The Linux server will -need to be configured properly to enable DPDK. - -DPDK requires a uio (User space I/O) or vfio (Virtual Function I/O) kernel module to be installed on the host to work. -There are 2 main uio kernel modules implementations (igb_uio and uio_pci_generic) and one vfio kernel module implementation. - -To check if a uio or vfio is already loaded on the host: - -.. code-block:: bash - - lsmod | grep -e igb_uio -e uio_pci_generic -e vfio - - -If missing, it is necessary to install a uio/vfio kernel module on the host server: - -- find a suitable kernel module for your host server (any uio or vfio kernel module built with the same Linux kernel version should work) -- load it using the modprobe and insmod commands - -Example of installation of the igb_uio kernel module: - -.. code-block:: bash - - modprobe uio - insmod ./igb_uio.ko - -Finally, the correct iommu options and huge pages to be configured on the Linux server on the boot command line: - -- enable intel_iommu and iommu pass through: "intel_iommu=on iommu=pt" -- for Trex, pre-allocate 1024 huge pages of 2MB each (for a total of 2GB): "hugepagesz=2M hugepages=1024" - -More detailed instructions can be found in the DPDK documentation (https://media.readthedocs.org/pdf/dpdk/latest/dpdk.pdf). diff --git a/docs/testing/user/userguide/images/extchain-config.png b/docs/testing/user/userguide/images/extchain-config.png Binary files differdeleted file mode 100644 index 2fd39ba..0000000 --- a/docs/testing/user/userguide/images/extchain-config.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-all-sriov-pvvp.png b/docs/testing/user/userguide/images/nfvbench-all-sriov-pvvp.png Binary files differdeleted file mode 100644 index d7b1cbb..0000000 --- a/docs/testing/user/userguide/images/nfvbench-all-sriov-pvvp.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-all-sriov-pvvp2.png b/docs/testing/user/userguide/images/nfvbench-all-sriov-pvvp2.png Binary files differdeleted file mode 100644 index 3d161cd..0000000 --- a/docs/testing/user/userguide/images/nfvbench-all-sriov-pvvp2.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-ext-multi-vlans.png b/docs/testing/user/userguide/images/nfvbench-ext-multi-vlans.png Binary files differdeleted file mode 100644 index 2ef2300..0000000 --- a/docs/testing/user/userguide/images/nfvbench-ext-multi-vlans.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-ext-shared.png b/docs/testing/user/userguide/images/nfvbench-ext-shared.png Binary files differdeleted file mode 100644 index efe1c71..0000000 --- a/docs/testing/user/userguide/images/nfvbench-ext-shared.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-npvp.png b/docs/testing/user/userguide/images/nfvbench-npvp.png Binary files differdeleted file mode 100644 index 53d7b00..0000000 --- a/docs/testing/user/userguide/images/nfvbench-npvp.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-pvp.png b/docs/testing/user/userguide/images/nfvbench-pvp.png Binary files differdeleted file mode 100644 index b460beb..0000000 --- a/docs/testing/user/userguide/images/nfvbench-pvp.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-pvvp.png b/docs/testing/user/userguide/images/nfvbench-pvvp.png Binary files differdeleted file mode 100644 index d412b20..0000000 --- a/docs/testing/user/userguide/images/nfvbench-pvvp.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-pvvp2.png b/docs/testing/user/userguide/images/nfvbench-pvvp2.png Binary files differdeleted file mode 100644 index 94f84de..0000000 --- a/docs/testing/user/userguide/images/nfvbench-pvvp2.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-sriov-pvp.png b/docs/testing/user/userguide/images/nfvbench-sriov-pvp.png Binary files differdeleted file mode 100644 index 7faec17..0000000 --- a/docs/testing/user/userguide/images/nfvbench-sriov-pvp.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-sriov-pvvp.png b/docs/testing/user/userguide/images/nfvbench-sriov-pvvp.png Binary files differdeleted file mode 100644 index 5faf8b2..0000000 --- a/docs/testing/user/userguide/images/nfvbench-sriov-pvvp.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-sriov-pvvp2.png b/docs/testing/user/userguide/images/nfvbench-sriov-pvvp2.png Binary files differdeleted file mode 100644 index f0c1e93..0000000 --- a/docs/testing/user/userguide/images/nfvbench-sriov-pvvp2.png +++ /dev/null diff --git a/docs/testing/user/userguide/images/nfvbench-trex-setup.png b/docs/testing/user/userguide/images/nfvbench-trex-setup.png Binary files differdeleted file mode 100644 index 6268068..0000000 --- a/docs/testing/user/userguide/images/nfvbench-trex-setup.png +++ /dev/null diff --git a/docs/testing/user/userguide/index.rst b/docs/testing/user/userguide/index.rst deleted file mode 100644 index e83912f..0000000 --- a/docs/testing/user/userguide/index.rst +++ /dev/null @@ -1,31 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - - -.. NFVBench documentation master file, created by - sphinx-quickstart on Thu Sep 29 14:25:18 2016. - - -******************* -NFVbench User Guide -******************* - -The NFVbench tool provides an automated way to measure the network performance for the most common data plane packet flows on any OpenStack system. -It is designed to be easy to install and easy to use by non experts (no need to be an expert in traffic generators and data plane performance testing). - - -Table of Content ----------------- -.. toctree:: - :maxdepth: 3 - - readme - installation - examples - advanced - extchains - fluentd - sriov - server - faq diff --git a/docs/testing/user/userguide/installation.rst b/docs/testing/user/userguide/installation.rst deleted file mode 100644 index 8a0511a..0000000 --- a/docs/testing/user/userguide/installation.rst +++ /dev/null @@ -1,14 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - -=================================== -Installation and Quick Start Guides -=================================== - -.. toctree:: - :maxdepth: 2 - - hw_requirements - quickstart_docker - diff --git a/docs/testing/user/userguide/quickstart_docker.rst b/docs/testing/user/userguide/quickstart_docker.rst deleted file mode 100644 index 6803bc3..0000000 --- a/docs/testing/user/userguide/quickstart_docker.rst +++ /dev/null @@ -1,243 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - -=========================================== -NFVbench Installation and Quick Start Guide -=========================================== - -.. _docker_installation: - -Make sure you satisfy the `hardware and software requirements <requirements>` before you start . - - -1. Container installation -------------------------- - -To pull the latest NFVbench container image: - -.. code-block:: bash - - docker pull opnfv/nfvbench - -2. Docker Container configuration ---------------------------------- - -The NFVbench container requires the following Docker options to operate properly. - -+-------------------------------------------------------+-------------------------------------------------------+ -| Docker options | Description | -+=======================================================+=======================================================+ -| -v /lib/modules/$(uname -r):/lib/modules/$(uname -r) | needed by kernel modules in the container | -+-------------------------------------------------------+-------------------------------------------------------+ -| -v /usr/src/kernels:/usr/src/kernels | needed by TRex to build kernel modules when needed | -+-------------------------------------------------------+-------------------------------------------------------+ -| -v /dev:/dev | needed by kernel modules in the container | -+-------------------------------------------------------+-------------------------------------------------------+ -| -v $PWD:/tmp/nfvbench | optional but recommended to pass files between the | -| | host and the docker space (see examples below) | -| | Here we map the current directory on the host to the | -| | /tmp/nfvbench director in the container but any | -| | other similar mapping can work as well | -+-------------------------------------------------------+-------------------------------------------------------+ -| --net=host | (optional) needed if you run the NFVbench | -| | server in the container (or use any appropriate | -| | docker network mode other than "host") | -+-------------------------------------------------------+-------------------------------------------------------+ -| --privileged | (optional) required if SELinux is enabled on the host | -+-------------------------------------------------------+-------------------------------------------------------+ -| -e HOST="127.0.0.1" | (optional) required if REST server is enabled | -+-------------------------------------------------------+-------------------------------------------------------+ -| -e PORT=7556 | (optional) required if REST server is enabled | -+-------------------------------------------------------+-------------------------------------------------------+ -| -e CONFIG_FILE="/root/nfvbenchconfig.json | (optional) required if REST server is enabled | -+-------------------------------------------------------+-------------------------------------------------------+ - -It can be convenient to write a shell script (or an alias) to automatically insert the necessary options. - -The minimal configuration file required must specify the PCI addresses of the 2 NIC ports to use. -If OpenStack is used, the openrc_file property must be defined to point to a valid OpenStack rc file. - - -Here is an example of mimimal configuration using OpenStack where: - -- the openrc file is located on the host current directory which is mapped under /tmp/nfvbench in the container (this is achieved using -v $PWD:/tmp/nfvbench) -- the 2 NIC ports to use for generating traffic have the PCI addresses "04:00.0" and "04:00.1" - -.. code-block:: bash - - { - "openrc_file": "/tmp/nfvbench/openrc", - "traffic_generator": { - "generator_profile": [ - { - "interfaces": [ - { - "pci": "04:00.0", - "port": 0, - }, - { - "pci": "04:00.1", - "port": 1, - } - ], - "intf_speed": "", - "ip": "127.0.0.1", - "name": "trex-local", - "software_mode": false, - "tool": "TRex" - } - ] - } - } - -The other options in the minimal configuration must be present and must have the same values as above. - -3. Start the Docker container ------------------------------ -As for any Docker container, you can execute NFVbench measurement sessions using a temporary container ("docker run" - which exits after each NFVbench run) -or you can decide to run the NFVbench container in the background then execute one or more NFVbench measurement sessions on that container ("docker exec"). - -The former approach is simpler to manage (since each container is started and terminated after each command) but incurs a small delay at start time (several seconds). -The second approach is more responsive as the delay is only incurred once when starting the container. - -We will take the second approach and start the NFVbench container in detached mode with the name "nfvbench" (this works with bash, prefix with "sudo" if you do not use the root login) - -First create a new working directory, and change the current working directory to there. A "nfvbench_ws" directory under your home directory is good place for that, and this is where the OpenStack RC file and NFVbench config file will sit. - -To run NFVBench without server mode - -.. code-block:: bash - - cd ~/nfvbench_ws - docker run --detach --net=host --privileged -v $PWD:/tmp/nfvbench -v /dev:/dev -v /lib/modules/$(uname -r):/lib/modules/$(uname -r) -v /usr/src/kernels:/usr/src/kernels --name nfvbench opnfv/nfvbench - -To run NFVBench enabling REST server (mount the configuration json and the path for openrc) - -.. code-block:: bash - - cd ~/nfvbench_ws - docker run --detach --net=host --privileged -e HOST="127.0.0.1" -e PORT=7556 -e CONFIG_FILE="/tmp/nfvbench/nfvbenchconfig.json -v $PWD:/tmp/nfvbench -v /dev:/dev -v /lib/modules/$(uname -r):/lib/modules/$(uname -r) -v /usr/src/kernels:/usr/src/kernels --name nfvbench opnfv/nfvbench start_rest_server - - -The create an alias to make it easy to execute nfvbench commands directly from the host shell prompt: - -.. code-block:: bash - - alias nfvbench='docker exec -it nfvbench nfvbench' - -The next to last "nfvbench" refers to the name of the container while the last "nfvbench" refers to the NFVbench binary that is available to run in the container. - -To verify it is working: - -.. code-block:: bash - - nfvbench --version - nfvbench --help - - -4. NFVbench configuration -------------------------- - -Create a new file containing the minimal configuration for NFVbench, we can call it any name, for example "my_nfvbench.cfg" and paste the following yaml template in the file: - -.. code-block:: bash - - openrc_file: - traffic_generator: - generator_profile: - - name: trex-local - tool: TRex - ip: 127.0.0.1 - cores: 3 - software_mode: false, - interfaces: - - port: 0 - pci: - - port: 1 - pci: - intf_speed: - -If OpenStack is used, NFVbench requires an ``openrc`` file to connect to OpenStack using the OpenStack API. This file can be downloaded from the OpenStack Horizon dashboard (refer to the OpenStack documentation on how to -retrieve the openrc file). The file pathname in the container must be stored in the "openrc_file" property. If it is stored on the host in the current directory, its full pathname must start with /tmp/nfvbench (since the current directory is mapped to /tmp/nfvbench in the container). - -If OpenStack is not used, remove the openrc_file property. - -The PCI address of the 2 physical interfaces that will be used by the traffic generator must be configured. -The PCI address can be obtained for example by using the "lspci" Linux command. For example: - -.. code-block:: bash - - [root@sjc04-pod6-build ~]# lspci | grep 710 - 0a:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01) - 0a:00.1 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01) - 0a:00.2 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01) - 0a:00.3 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01) - - -Example of edited configuration with an OpenStack RC file stored in the current directory with the "openrc" name, and -PCI addresses "0a:00.0" and "0a:00.1" (first 2 ports of the quad port NIC): - -.. code-block:: bash - - openrc_file: /tmp/nfvbench/openrc - traffic_generator: - generator_profile: - - name: trex-local - tool: TRex - ip: 127.0.0.1 - cores: 3 - software_mode: false, - interfaces: - - port: 0 - switch_port: - pci: "0a:00.0" - - port: 1 - switch_port: - pci: "0a:00.1" - intf_speed: - -.. warning:: - - You have to put quotes around the pci addresses as shown in the above example, otherwise TRex will read it wrong. - -Alternatively, the full template with comments can be obtained using the --show-default-config option in yaml format: - -.. code-block:: bash - - nfvbench --show-default-config > my_nfvbench.cfg - -Edit the nfvbench.cfg file to only keep those properties that need to be modified (preserving the nesting). - -Make sure you have your nfvbench configuration file (my_nfvbench.cfg) and - if OpenStack is used - OpenStack RC file in your pre-created working directory. - - -5. Run NFVbench ---------------- - -To do a single run at 10,000pps bi-directional (or 5kpps in each direction) using the PVP packet path: - -.. code-block:: bash - - nfvbench -c /tmp/nfvbench/my_nfvbench.cfg --rate 10kpps - -NFVbench options used: - -* ``-c /tmp/nfvbench/my_nfvbench.cfg`` : specify the config file to use (this must reflect the file path from inside the container) -* ``--rate 10kpps`` : specify rate of packets for test for both directions using the kpps unit (thousands of packets per second) - -This should produce a result similar to this (a simple run with the above options should take less than 5 minutes): - -.. code-block:: none - - [TBP] - - -7. Terminating the NFVbench container -------------------------------------- -When no longer needed, the container can be terminated using the usual docker commands: - -.. code-block:: bash - - docker kill nfvbench - docker rm nfvbench diff --git a/docs/testing/user/userguide/readme.rst b/docs/testing/user/userguide/readme.rst deleted file mode 100644 index acd4763..0000000 --- a/docs/testing/user/userguide/readme.rst +++ /dev/null @@ -1,195 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - -Features -******** - -Data Plane Performance Measurement Features -------------------------------------------- - -NFVbench supports the following main measurement capabilities: - -- supports 2 measurement modes: - - *fixed rate* mode to generate traffic at a fixed rate for a fixed duration - - NDR (No Drop Rate) and PDR (Partial Drop Rate) measurement mode -- configurable frame sizes (any list of fixed sizes or 'IMIX') -- built-in packet paths (PVP, PVVP) -- built-in loopback VNFs based on fast L2 or L3 forwarders running in VMs -- configurable number of flows and service chains -- configurable traffic direction (single or bi-directional) -- can support optional VLAN tagging (dot1q) or VxLAN overlays - - -NDR is the highest throughput achieved without dropping packets. -PDR is the highest throughput achieved without dropping more than a pre-set limit (called PDR threshold or allowance, expressed in %). - -Results of each run include the following data: - -- Aggregated achieved throughput in bps -- Aggregated achieved packet rate in pps (or fps) -- Actual drop rate in % -- Latency in usec (min, max, average in the current version) - -Built-in OpenStack support (optional) -------------------------------------- -NFVbench can optionally stage OpenStack resources to build 1 or more service chains using direct OpenStack APIs. Each service chain is composed of: - -- 1 or 2 loopback VM instances per service chain -- 2 Neutron networks per loopback VM - -OpenStack resources are staged before traffic is measured using OpenStack APIs (Nova and Neutron) then disposed after completion of measurements. - -The loopback VM flavor to use can be configured in the NFVbench configuration file. - -Note that NFVbench does not use OpenStack Heat nor any higher level service (VNFM or NFVO) to create the service chains because its -main purpose is to measure the performance of the NFVi infrastructure which is mainly focused on L2 forwarding performance. - -External Chains ---------------- -NFVbench supports settings that involve externally staged packet paths with or without OpenStack: - -- run benchmarks on existing service chains at the L3 level that are staged externally by any other tool (e.g. any VNF capable of L3 routing) -- run benchmarks on existing L2 chains that are configured externally (e.g. pure L2 forwarder such as DPDK testpmd) - -Direct L2 Loopback (Switch or wire loopback) --------------------------------------------- -NFVbench supports benchmarking of pure L2 loopbacks (see "--l2-loopback vlan" option) - -- Switch level loopback -- Port to port wire loopback - -In this mode, NFVbench will take a vlan ID and send packets from each port to the other port -(dest MAC set to the other port MAC) using the same VLAN ID on both ports. -This can be useful for example to verify that the connectivity to the switch is working properly. - -Traffic Generation ------------------- - -NFVbench currently integrates with the open source TRex traffic generator: - -- `TRex <https://trex-tgn.cisco.com>`_ (pre-built into the NFVbench container) - - -Supported Packet Paths ----------------------- -Packet paths describe where packets are flowing in the NFVi platform. The most commonly used paths are identified by 3 or 4 letter abbreviations. -A packet path can generally describe the flow of packets associated to one or more service chains, with each service chain composed of 1 or more VNFs. - -The following packet paths are currently supported by NFVbench: - -- PVP (Physical interface to VM to Physical interface) -- PVVP (Physical interface to VM to VM to Physical interface) -- N*PVP (N concurrent PVP packet paths) -- N*PVVP (N concurrent PVVP packet paths) - -The traffic is made of 1 or more flows of L3 frames (UDP packets) with different payload sizes. Each flow is identified by a unique source and destination MAC/IP tuple. - - -Loopback VM -^^^^^^^^^^^ - -NFVbench provides a loopback VM image that runs CentOS with 2 pre-installed forwarders: - -- DPDK testpmd configured to do L2 cross connect between 2 virtual interfaces -- FD.io VPP configured to perform L3 routing between 2 virtual interfaces - -Frames are just forwarded from one interface to the other. -In the case of testpmd, the source and destination MAC are rewritten, which corresponds to the mac forwarding mode (--forward-mode=mac). -In the case of VPP, VPP will act as a real L3 router, and the packets are routed from one port to the other using static routes. - -Which forwarder and what Nova flavor to use can be selected in the NFVbench configuration. Be default the DPDK testpmd forwarder is used with 2 vCPU per VM. -The configuration of these forwarders (such as MAC rewrite configuration or static route configuration) is managed by NFVbench. - - -PVP Packet Path -^^^^^^^^^^^^^^^ - -This packet path represents a single service chain with 1 loopback VNF and 2 Neutron networks: - -.. image:: images/nfvbench-pvp.png - - -PVVP Packet Path -^^^^^^^^^^^^^^^^ - -This packet path represents a single service chain with 2 loopback VNFs in sequence and 3 Neutron networks. -The 2 VNFs will only run on the same compute node (PVVP intra-node): - -.. image:: images/nfvbench-pvvp.png - - -Multi-Chaining (N*PVP or N*PVVP) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Multiple service chains can be setup by NFVbench without any limit on the concurrency (other than limits imposed by available resources on compute nodes). -In the case of multiple service chains, NFVbench will instruct the traffic generator to use multiple L3 packet streams (frames directed to each path will -have a unique destination MAC address). - -Example of multi-chaining with 2 concurrent PVP service chains: - -.. image:: images/nfvbench-npvp.png - -This innovative feature will allow to measure easily the performance of a fully loaded compute node running multiple service chains. - -Multi-chaining is currently limited to 1 compute node (VMs run on the same compute node). -The 2 edge interfaces for all service chains can either share the same 2 networks or can use -dedicated networks (based on a configuration option). -The total traffic will be split equally across all chains. - - -SR-IOV -^^^^^^ - -By default, service chains will be based on virtual switch interfaces. - -NFVbench provides an option to select SR-IOV based virtual interfaces instead (thus bypassing any virtual switch) for those OpenStack system that include and support SR-IOV capable NICs on compute nodes. - -The PVP packet path will bypass the virtual switch completely when the SR-IOV option is selected: - -.. image:: images/nfvbench-sriov-pvp.png - -The PVVP packet path will use SR-IOV for the left and right networks and the virtual switch for the middle network by default: - -.. image:: images/nfvbench-sriov-pvvp.png - -Or in the case of inter-node: - -.. image:: images/nfvbench-sriov-pvvp2.png - -This packet path is a good way to approximate VM to VM (V2V) performance (middle network) given the high efficiency of the left and right networks. The V2V throughput will likely be very close to the PVVP throughput while its latency will be very close to the difference between the SR-IOV PVVP latency and the SR-IOV PVP latency. - -It is possible to also force the middle network to use SR-IOV (in this version, the middle network is limited to use the same SR-IOV phys net): - -.. image:: images/nfvbench-all-sriov-pvvp.png - -The chain can also span across 2 nodes with the use of 2 SR-IOV ports in each node: - -.. image:: images/nfvbench-all-sriov-pvvp2.png - - -Other Misc Packet Paths -^^^^^^^^^^^^^^^^^^^^^^^ - -P2P (Physical interface to Physical interface - no VM) can be supported using the external chain/L2 forwarding mode. - -V2V (VM to VM) is not supported but PVVP provides a more complete (and more realistic) alternative. - - -Supported Neutron Network Plugins and vswitches ------------------------------------------------ - -Any Virtual Switch, Any Encapsulation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -NFVbench is agnostic of the virtual switch implementation and has been tested with the following virtual switches: - -- ML2/VPP/VLAN (networking-vpp) -- OVS/VLAN and OVS-DPDK/VLAN -- ML2/ODL/VPP (OPNFV Fast Data Stack) - - - -Limitations -*********** -VxLAN: latency measurement and per chain stats is not available in the first VxLAN release diff --git a/docs/testing/user/userguide/server.rst b/docs/testing/user/userguide/server.rst deleted file mode 100644 index 921e3bc..0000000 --- a/docs/testing/user/userguide/server.rst +++ /dev/null @@ -1,438 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - -NFVbench Server mode and NFVbench client API -============================================ - -NFVbench can run as an HTTP server to: - -- optionally provide access to any arbitrary HTLM files (HTTP server function) - this is optional -- service fully parameterized aynchronous run requests using the HTTP protocol (REST/json with polling) -- service fully parameterized run requests with interval stats reporting using the WebSocket/SocketIO protocol. - -Start the NFVbench server -------------------------- -To run in server mode, simply use the --server <http_root_path> and optionally the listen address to use (--host <ip>, default is 0.0.0.0) and listening port to use (--port <port>, default is 7555). - - -If HTTP files are to be serviced, they must be stored right under the http root path. -This root path must contain a static folder to hold static files (css, js) and a templates folder with at least an index.html file to hold the template of the index.html file to be used. -This mode is convenient when you do not already have a WEB server hosting the UI front end. -If HTTP files servicing is not needed (REST only or WebSocket/SocketIO mode), the root path can point to any dummy folder. - -Once started, the NFVbench server will be ready to service HTTP or WebSocket/SocketIO requests at the advertised URL. - -Example of NFVbench server start in a container: - -.. code-block:: bash - - # get to the container shell (assume the container name is "nfvbench") - docker exec -it nfvbench bash - # from the container shell start the NFVbench server in the background - nfvbench -c /tmp/nfvbench/nfvbench.cfg --server /tmp & - # exit container - exit - - - -HTTP Interface --------------- - -<http-url>/echo (GET) -^^^^^^^^^^^^^^^^^^^^^ - -This request simply returns whatever content is sent in the body of the request (body should be in json format, only used for testing) - -Example request: - -.. code-block:: bash - - curl -XGET '127.0.0.1:7556/echo' -H "Content-Type: application/json" -d '{"nfvbench": "test"}' - Response: - { - "nfvbench": "test" - } - - -<http-url>/status (GET) -^^^^^^^^^^^^^^^^^^^^^^^ - -This request fetches the status of an asynchronous run. It will return in json format: - -- a request pending reply (if the run is still not completed) -- an error reply if there is no run pending -- or the complete result of the run - -The client can keep polling until the run completes. - -Example of return when the run is still pending: - -.. code-block:: bash - - { - "error_message": "nfvbench run still pending", - "status": "PENDING" - } - -Example of return when the run completes: - -.. code-block:: bash - - { - "result": {...} - "status": "OK" - } - - -<http-url>/start_run (POST) -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This request starts an NFVBench run with passed configurations. If no configuration is passed, a run with default configurations will be executed. - -Example request: curl -XPOST 'localhost:7556/start_run' -H "Content-Type: application/json" -d @nfvbenchconfig.json - -See "NFVbench configuration JSON parameter" below for details on how to format this parameter. - -The request returns immediately with a json content indicating if there was an error (status=ERROR) or if the request was submitted successfully (status=PENDING). -Example of return when the submission is successful: - -.. code-block:: bash - - { - "error_message": "NFVbench run still pending", - "request_id": "42cccb7effdc43caa47f722f0ca8ec96", - "status": "PENDING" - } - -If there is already an NFVBench running then it will return: - -.. code-block:: bash - - { - "error_message": "there is already an NFVbench request running", - "status": "ERROR" - } - -WebSocket/SocketIO events -------------------------- - -List of SocketIO events supported: - -Client to Server -^^^^^^^^^^^^^^^^ - -start_run: - - sent by client to start a new run with the configuration passed in argument (JSON). - The configuration can be any valid NFVbench configuration passed as a JSON document (see "NFVbench configuration JSON parameter" below) - -Server to Client -^^^^^^^^^^^^^^^^ - -run_interval_stats: - - sent by server to report statistics during a run - the message contains the statistics {'time_ms': time_ms, 'tx_pps': tx_pps, 'rx_pps': rx_pps, 'drop_pct': drop_pct} - -ndr_found: - - (during NDR-PDR search) - sent by server when the NDR rate is found - the message contains the NDR value {'rate_pps': ndr_pps} - -ndr_found: - - (during NDR-PDR search) - sent by server when the PDR rate is found - the message contains the PDR value {'rate_pps': pdr_pps} - - -run_end: - - sent by server to report the end of a run - the message contains the complete results in JSON format - -NFVbench configuration JSON parameter -------------------------------------- -The NFVbench configuration describes the parameters of an NFVbench run and can be passed to the NFVbench server as a JSON document. - -Default configuration -^^^^^^^^^^^^^^^^^^^^^ - -The simplest JSON document is the empty dictionary "{}" which indicates to use the default NFVbench configuration: - -- PVP -- NDR-PDR measurement -- 64 byte packets -- 1 flow per direction - -The entire default configuration can be viewed using the --show-json-config option on the cli: - -.. code-block:: bash - - # nfvbench --show-config - { - "availability_zone": null, - "compute_node_user": "root", - "compute_nodes": null, - "debug": false, - "duration_sec": 60, - "flavor": { - "disk": 0, - "extra_specs": { - "hw:cpu_policy": "dedicated", - "hw:mem_page_size": 2048 - }, - "ram": 8192, - "vcpus": 2 - }, - "flavor_type": "nfv.medium", - "flow_count": 1, - "generic_poll_sec": 2, - "generic_retry_count": 100, - "inter_node": false, - "internal_networks": { - "left": { - "name": "nfvbench-net0", - "subnet": "nfvbench-subnet0", - "cidr": "192.168.1.0/24", - }, - "right": { - "name": "nfvbench-net1", - "subnet": "nfvbench-subnet1", - "cidr": "192.168.2.0/24", - }, - "middle": { - "name": "nfvbench-net2", - "subnet": "nfvbench-subnet2", - "cidr": "192.168.3.0/24", - } - }, - "interval_sec": 10, - "json": null, - "loop_vm_name": "nfvbench-loop-vm", - "measurement": { - "NDR": 0.001, - "PDR": 0.1, - "load_epsilon": 0.1 - }, - "name": "(built-in default config)", - "no_cleanup": false, - "no_traffic": false, - "openrc_file": "/tmp/nfvbench/openstack/openrc", - "rate": "ndr_pdr", - "service_chain": "PVP", - "service_chain_count": 1, - "sriov": false, - "std_json": null, - "traffic": { - "bidirectional": true, - "profile": "traffic_profile_64B" - }, - "traffic_generator": { - "default_profile": "trex-local", - "gateway_ip_addrs": [ - "1.1.0.2", - "2.2.0.2" - ], - "gateway_ip_addrs_step": "0.0.0.1", - "generator_profile": [ - { - "cores": 3, - "interfaces": [ - { - "pci": "0a:00.0", - "port": 0, - "switch_port": "Ethernet1/33", - "vlan": null - }, - { - "pci": "0a:00.1", - "port": 1, - "switch_port": "Ethernet1/34", - "vlan": null - } - ], - "intf_speed": null, - "ip": "127.0.0.1", - "name": "trex-local", - "tool": "TRex" - } - ], - "host_name": "nfvbench_tg", - "ip_addrs": [ - "10.0.0.0/8", - "20.0.0.0/8" - ], - "ip_addrs_step": "0.0.0.1", - "mac_addrs": [ - "00:10:94:00:0A:00", - "00:11:94:00:0A:00" - ], - "step_mac": null, - "tg_gateway_ip_addrs": [ - "1.1.0.100", - "2.2.0.100" - ], - "tg_gateway_ip_addrs_step": "0.0.0.1" - }, - "traffic_profile": [ - { - "l2frame_size": [ - "64" - ], - "name": "traffic_profile_64B" - }, - { - "l2frame_size": [ - "IMIX" - ], - "name": "traffic_profile_IMIX" - }, - { - "l2frame_size": [ - "1518" - ], - "name": "traffic_profile_1518B" - }, - { - "l2frame_size": [ - "64", - "IMIX", - "1518" - ], - "name": "traffic_profile_3sizes" - } - ], - "unidir_reverse_traffic_pps": 1, - "vlan_tagging": true, - } - - -Common examples of JSON configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use the default configuration but use 10000 flows per direction (instead of 1): - -.. code-block:: bash - - { "flow_count": 10000 } - - -Use default confguration but with 10000 flows, "EXT" chain and IMIX packet size: - -.. code-block:: bash - - { - "flow_count": 10000, - "service_chain": "EXT", - "traffic": { - "profile": "traffic_profile_IMIX" - }, - } - -A short run of 5 seconds at a fixed rate of 1Mpps (and everything else same as the default configuration): - -.. code-block:: bash - - { - "duration": 5, - "rate": "1Mpps" - } - -Example of interaction with the NFVbench server using HTTP and curl -------------------------------------------------------------------- -HTTP requests can be sent directly to the NFVbench server from CLI using curl from any host that can connect to the server (here we run it from the local host). - -This is a POST request to start a run using the default NFVbench configuration but with traffic generation disabled ("no_traffic" property is set to true): - -.. code-block:: bash - - [root@sjc04-pod3-mgmt ~]# curl -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"no_traffic":true}' http://127.0.0.1:7555/start_run - { - "error_message": "nfvbench run still pending", - "status": "PENDING" - } - [root@sjc04-pod3-mgmt ~]# - -This request will return immediately with status set to "PENDING" if the request was started successfully. - -The status can be polled until the run completes. Here the poll returns a "PENDING" status, indicating the run is still not completed: - -.. code-block:: bash - - [root@sjc04-pod3-mgmt ~]# curl -G http://127.0.0.1:7555/status - { - "error_message": "nfvbench run still pending", - "status": "PENDING" - } - [root@sjc04-pod3-mgmt ~]# - -Finally, the status request returns a "OK" status along with the full results (truncated here): - -.. code-block:: bash - - [root@sjc04-pod3-mgmt ~]# curl -G http://127.0.0.1:7555/status - { - "result": { - "benchmarks": { - "network": { - "service_chain": { - "PVP": { - "result": { - "bidirectional": true, - "compute_nodes": { - "nova:sjc04-pod3-compute-4": { - "bios_settings": { - "Adjacent Cache Line Prefetcher": "Disabled", - "All Onboard LOM Ports": "Enabled", - "All PCIe Slots OptionROM": "Enabled", - "Altitude": "300 M", - ... - - "date": "2017-03-31 22:15:41", - "nfvbench_version": "0.3.5", - "openstack_spec": { - "encaps": "VxLAN", - "vswitch": "VTS" - } - }, - "status": "OK" - } - [root@sjc04-pod3-mgmt ~]# - - - -Example of interaction with the NFVbench server using a python CLI app (nfvbench_client) ----------------------------------------------------------------------------------------- -The module client/client.py contains an example of python class that can be used to control the NFVbench server from a python app using HTTP or WebSocket/SocketIO. - -The module client/nfvbench_client.py has a simple main application to control the NFVbench server from CLI. -The "nfvbench_client" wrapper script can be used to invoke the client front end (this wrapper is pre-installed in the NFVbench container) - -Example of invocation of the nfvbench_client front end, from the host (assume the name of the NFVbench container is "nfvbench"), -use the default NFVbench configuration but do not generate traffic (no_traffic property set to true, the full json result is truncated here): - -.. code-block:: bash - - [root@sjc04-pod3-mgmt ~]# docker exec -it nfvbench nfvbench_client -c '{"no_traffic":true}' http://127.0.0.1:7555 - {u'status': u'PENDING', u'error_message': u'nfvbench run still pending'} - {u'status': u'PENDING', u'error_message': u'nfvbench run still pending'} - {u'status': u'PENDING', u'error_message': u'nfvbench run still pending'} - - {u'status': u'OK', u'result': {u'date': u'2017-03-31 22:04:59', u'nfvbench_version': u'0.3.5', - u'config': {u'compute_nodes': None, u'compute_node_user': u'root', u'traffic_generator': {u'tg_gateway_ip_addrs': [u'1.1.0.100', u'2.2.0.100'], u'ip_addrs_step': u'0.0.0.1', - u'step_mac': None, u'generator_profile': [{u'intf_speed': u'', u'interfaces': [{u'pci': u'0a:00.0', u'port': 0, u'vlan': 1998, u'switch_port': None}, - - ... - - [root@sjc04-pod3-mgmt ~]# - -The http interface is used unless --use-socketio is defined. - -Example of invocation using Websocket/SocketIO, execute NFVbench using the default configuration but with a duration of 5 seconds and a fixed rate run of 5kpps. - -.. code-block:: bash - - [root@sjc04-pod3-mgmt ~]# docker exec -it nfvbench nfvbench_client -c '{"duration":5,"rate":"5kpps"}' --use-socketio http://127.0.0.1:7555 >results.json diff --git a/docs/testing/user/userguide/sriov.rst b/docs/testing/user/userguide/sriov.rst deleted file mode 100644 index f5cc7d2..0000000 --- a/docs/testing/user/userguide/sriov.rst +++ /dev/null @@ -1,462 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. SPDX-License-Identifier: CC-BY-4.0 -.. (c) Cisco Systems, Inc - - -Testing SR-IOV -============== - -NFVbench supports SR-IOV with the PVP and PVVP packet flow. Most use cases for SR-IOV only require single VNF chains (NxPVP). -Daisy chaining VNFs with SR-IOV (PVVP) requires selecting either SR-IOV for the middle network or a fast vswitch (using the -standard OVS for that purpose works but would be a serious bottleneck) - -Instructions below refer to the PVP or PVVP use cases. -For external chains using SR-IOV, select the VLAN tagging option that corresponds to the external chains SR-IOV setting. - -Pre-requisites --------------- -To test SR-IOV you need to have compute nodes configured to support one or more SR-IOV interfaces (also knows as PF or physical function) -and you need OpenStack to be configured to support SR-IOV. -You will also need to know: -- the name of the physical networks associated to the SR-IOV interfaces (this is a configuration in Nova compute) -- the VLAN range that can be used on the switch ports that are wired to the SR-IOV ports. Such switch ports are normally configured in trunk mode with a range of VLAN ids enabled on that port - -For example, in the case of 2 SR-IOV ports per compute node, 2 physical networks are generally configured in OpenStack with a distinct name. -The VLAN range to use is is also allocated and reserved by the network administrator and in coordination with the corresponding top of rack switch port configuration. - - -Configuration -------------- -To enable SR-IOV test, you will need to provide the following configuration options to NFVbench (in the configuration file). -This example instructs NFVbench to create the left and right networks of a PVP packet flow to run on 2 SRIOV ports named "phys_sriov0" and "phys_sriov1" using resp. segmentation_id 2000 and 2001: - -.. code-block:: bash - - sriov: true - internal_networks: - left: - segmentation_id: 2000 - physical_network: phys_sriov0 - right: - segmentation_id: 2001 - physical_network: phys_sriov1 - -The segmentation ID fields must be different. -In the case of PVVP, the middle network also needs to be provisioned properly. -The same physical network can also be shared by the virtual networks but with different segmentation IDs. - -Multi-Chaining --------------- -The above configuration works for multi-chaining and shared network ("service_chain_shared_net" set to true). -In that case all VNFs will share the same left and right network/VLAN. - -In the case of non shared network ("service_chain_shared_net" set to false), the segmentation_id fields must -contain a list of distinct VLANs to use for each chain. Example of configuration for 3 chains: - -.. code-block:: bash - - sriov: true - internal_networks: - left: - segmentation_id: [2000, 2001, 2002] - physical_network: phys_sriov0 - right: - segmentation_id: [2100, 2101, 2102] - physical_network: phys_sriov1 - -Alternatively it is also possible to specify different physnets per chain: - -.. code-block:: bash - - sriov: true - internal_networks: - left: - segmentation_id: [2000, 2001, 2002] - physical_network: [phys_sriov0, phys_sriov2, phys_sriov4] - right: - segmentation_id: [2100, 2101, 2102] - physical_network: [phys_sriov1, phys_srviov3, phys_sriov5] - - -NFVbench cores with SR-IOV --------------------------- -The default core count for NFVbench/TRex may not be sufficient for higher throughput line cards (greater than 10Gbps). -This will result in warning messages such as: - -.. code-block:: bash - - INFO WARNING: There is a significant difference between requested TX rate (119047618) and actual TX rate (38897379). - The traffic generator may not have sufficient CPU to achieve the requested TX rate. - -In that case it is recommended to try allocating more cores to TRex using the cores property in the configuration -file, for example to set to 8 cores: - -.. code-block:: bash - - cores: 8 - -It is also advisable to increase the number of vcpus in the VMs: - - -VM Flavor for SR-IOV and NIC NUMA socket placement --------------------------------------------------- - -Because SR-IOV throughput uses a lot of CPU in the VM, it is recommended to increase the -vcpu count, for example to 4 vcpus: - -.. code-block:: bash - - flavor: - # Number of vCPUs for the flavor - vcpus: 4 - # Memory for the flavor in MB - ram: 8192 - # Size of local disk in GB - disk: 0 - extra_specs: - "hw:cpu_policy": dedicated - -If the 2 selected ports reside on NICs that are on different NUMA sockets, you will need to explicitly tell Nova to use 2 numa nodes in the flavor used for the VMs in order to satisfy the filters, for example: - -.. code-block:: bash - - flavor: - # Number of vCPUs for the flavor - vcpus: 4 - # Memory for the flavor in MB - ram: 8192 - # Size of local disk in GB - disk: 0 - extra_specs: - "hw:cpu_policy": dedicated - "hw:numa_nodes": 2 - -Failure to do so might cause the VM creation to fail with the Nova error -"Instance creation error: Insufficient compute resources: -Requested instance NUMA topology together with requested PCI devices cannot fit the given host NUMA topology." - -Example of configuration file (shared network) ----------------------------------------------- - -Single chain or multi-chain with shared network (only requires 2 segmentation ID for all chains): - -.. code-block:: bash - - flavor: - # Number of vCPUs for the flavor - vcpus: 4 - # Memory for the flavor in MB - ram: 8192 - # Size of local disk in GB - disk: 0 - extra_specs: - "hw:cpu_policy": dedicated - cores: 8 - sriov: true - internal_networks: - left: - segmentation_id: 3830 - physical_network: phys_sriov0 - right: - segmentation_id: 3831 - physical_network: phys_sriov1 - -Example of full run 2xPVP shared network SR-IOV: - -.. code-block:: bash - - 2018-12-03 18:24:07,419 INFO Loading configuration file: /tmp/nfvbench/sriov.yaml - 2018-12-03 18:24:07,423 INFO -c /tmp/nfvbench/sriov.yaml --rate 10Mpps --duration 1 -scc 2 --no-cleanup - 2018-12-03 18:24:07,426 INFO Connecting to TRex (127.0.0.1)... - 2018-12-03 18:24:07,575 INFO Connected to TRex - 2018-12-03 18:24:07,575 INFO Port 0: Ethernet Controller XL710 for 40GbE QSFP+ speed=40Gbps mac=3c:fd:fe:b5:3d:70 pci=0000:5e:00.0 driver=net_i40e - 2018-12-03 18:24:07,575 INFO Port 1: Ethernet Controller XL710 for 40GbE QSFP+ speed=40Gbps mac=3c:fd:fe:b5:3d:71 pci=0000:5e:00.1 driver=net_i40e - 2018-12-03 18:24:07,626 INFO Found built-in VM image file nfvbenchvm-0.6.qcow2 - 2018-12-03 18:24:09,072 INFO Created flavor 'nfvbench.medium' - 2018-12-03 18:24:10,004 INFO Created network: nfvbench-lnet. - 2018-12-03 18:24:10,837 INFO Created network: nfvbench-rnet. - 2018-12-03 18:24:12,065 INFO Security disabled on port nfvbench-loop-vm0-0 - 2018-12-03 18:24:13,425 INFO Security disabled on port nfvbench-loop-vm0-1 - 2018-12-03 18:24:13,425 INFO Creating instance nfvbench-loop-vm0 with AZ - 2018-12-03 18:24:16,052 INFO Created instance nfvbench-loop-vm0 - waiting for placement resolution... - 2018-12-03 18:24:16,240 INFO Waiting for instance nfvbench-loop-vm0 to become active (retry 1/101)... - <snip> - 2018-12-03 18:24:59,266 INFO Waiting for instance nfvbench-loop-vm0 to become active (retry 21/101)... - 2018-12-03 18:25:01,427 INFO Instance nfvbench-loop-vm0 is active and has been placed on nova:charter-compute-5 - 2018-12-03 18:25:02,819 INFO Security disabled on port nfvbench-loop-vm1-0 - 2018-12-03 18:25:04,198 INFO Security disabled on port nfvbench-loop-vm1-1 - 2018-12-03 18:25:04,199 INFO Creating instance nfvbench-loop-vm1 with AZ nova:charter-compute-5 - 2018-12-03 18:25:05,032 INFO Created instance nfvbench-loop-vm1 on nova:charter-compute-5 - 2018-12-03 18:25:05,033 INFO Instance nfvbench-loop-vm0 is ACTIVE on nova:charter-compute-5 - 2018-12-03 18:25:05,212 INFO Waiting for 1/2 instance to become active (retry 1/100)... - <snip> - 2018-12-03 18:25:48,531 INFO Waiting for 1/2 instance to become active (retry 21/100)... - 2018-12-03 18:25:50,677 INFO Instance nfvbench-loop-vm1 is ACTIVE on nova:charter-compute-5 - 2018-12-03 18:25:50,677 INFO All instances are active - 2018-12-03 18:25:50,677 INFO Port 0: VLANs [3830, 3830] - 2018-12-03 18:25:50,677 INFO Port 1: VLANs [3831, 3831] - 2018-12-03 18:25:50,677 INFO Port 0: dst MAC ['fa:16:3e:de:4e:54', 'fa:16:3e:7a:26:2b'] - 2018-12-03 18:25:50,677 INFO Port 1: dst MAC ['fa:16:3e:6c:bb:cd', 'fa:16:3e:e0:48:45'] - 2018-12-03 18:25:50,678 INFO ChainRunner initialized - 2018-12-03 18:25:50,678 INFO Starting 2xPVP benchmark... - 2018-12-03 18:25:50,683 INFO Starting traffic generator to ensure end-to-end connectivity - 2018-12-03 18:25:50,698 INFO Created 2 traffic streams for port 0. - 2018-12-03 18:25:50,700 INFO Created 2 traffic streams for port 1. - 2018-12-03 18:25:50,821 INFO Captured unique src mac 0/4, capturing return packets (retry 1/100)... - 2018-12-03 18:25:52,944 INFO Received packet from mac: fa:16:3e:de:4e:54 (chain=0, port=0) - 2018-12-03 18:25:52,945 INFO Received packet from mac: fa:16:3e:6c:bb:cd (chain=0, port=1) - 2018-12-03 18:25:53,077 INFO Captured unique src mac 2/4, capturing return packets (retry 2/100)... - <snip> - 2018-12-03 18:26:10,798 INFO End-to-end connectivity established - 2018-12-03 18:26:10,816 INFO Cleared all existing streams - 2018-12-03 18:26:10,846 INFO Created 4 traffic streams for port 0. - 2018-12-03 18:26:10,849 INFO Created 4 traffic streams for port 1. - 2018-12-03 18:26:10,849 INFO Starting to generate traffic... - 2018-12-03 18:26:10,850 INFO Running traffic generator - 2018-12-03 18:26:11,877 INFO TX: 10000004; RX: 9999999; Est. Dropped: 5; Est. Drop rate: 0.0000% - 2018-12-03 18:26:11,877 INFO ...traffic generating ended. - 2018-12-03 18:26:11,882 INFO Service chain 'PVP' run completed. - 2018-12-03 18:26:11,936 INFO Clean up skipped. - 2018-12-03 18:26:11,969 INFO - ========== NFVBench Summary ========== - Date: 2018-12-03 18:25:50 - NFVBench version 3.0.3.dev1 - Openstack Neutron: - vSwitch: OPENVSWITCH - Encapsulation: VLAN - Benchmarks: - > Networks: - > Components: - > Traffic Generator: - Profile: trex-local - Tool: TRex - > Versions: - > Traffic_Generator: - build_date: Nov 13 2017 - version: v2.32 - built_by: hhaim - mode: STL - build_time: 10:58:17 - > CiscoVIM: 2.9.7-17036 - > Service chain: - > PVP: - > Traffic: - Profile: traffic_profile_64B - Bidirectional: True - Flow count: 10000 - Service chains count: 2 - Compute nodes: [u'nova:charter-compute-5'] - - Run Summary: - - +-----------------+-------------+----------------------+----------------------+----------------------+ - | L2 Frame Size | Drop Rate | Avg Latency (usec) | Min Latency (usec) | Max Latency (usec) | - +=================+=============+======================+======================+======================+ - | 64 | 0.0000% | 13 | 10 | 141 | - +-----------------+-------------+----------------------+----------------------+----------------------+ - - - L2 frame size: 64 - - Run Config: - - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - | Direction | Requested TX Rate (bps) | Actual TX Rate (bps) | RX Rate (bps) | Requested TX Rate (pps) | Actual TX Rate (pps) | RX Rate (pps) | - +=============+===========================+========================+=================+===========================+========================+=================+ - | Forward | 336.0000 Mbps | 336.0000 Mbps | 336.0000 Mbps | 500,000 pps | 500,000 pps | 500,000 pps | - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - | Reverse | 336.0000 Mbps | 336.0000 Mbps | 336.0000 Mbps | 500,000 pps | 500,000 pps | 500,000 pps | - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - | Total | 672.0000 Mbps | 672.0000 Mbps | 672.0000 Mbps | 1,000,000 pps | 1,000,000 pps | 1,000,000 pps | - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - - Forward Chain Packet Counters and Latency: - - +---------+--------------+--------------+------------+------------+------------+ - | Chain | TRex.TX.p0 | TRex.RX.p1 | Avg lat. | Min lat. | Max lat. | - +=========+==============+==============+============+============+============+ - | 0 | 250,000 | 250,000 | 17 usec | 10 usec | 138 usec | - +---------+--------------+--------------+------------+------------+------------+ - | 1 | 250,000 | 250,000 | 17 usec | 10 usec | 139 usec | - +---------+--------------+--------------+------------+------------+------------+ - | total | 500,000 | 500,000 | 17 usec | 10 usec | 139 usec | - +---------+--------------+--------------+------------+------------+------------+ - - Reverse Chain Packet Counters and Latency: - - +---------+--------------+--------------+------------+------------+------------+ - | Chain | TRex.TX.p1 | TRex.RX.p0 | Avg lat. | Min lat. | Max lat. | - +=========+==============+==============+============+============+============+ - | 0 | 250,000 | 250,000 | 12 usec | 10 usec | 141 usec | - +---------+--------------+--------------+------------+------------+------------+ - | 1 | 250,000 | 250,000 | 11 usec | 10 usec | 132 usec | - +---------+--------------+--------------+------------+------------+------------+ - | total | 500,000 | 500,000 | 12 usec | 10 usec | 141 usec | - +---------+--------------+--------------+------------+------------+------------+ - -Example of configuration file (non shared network) --------------------------------------------------- - -Multi-chain with non shared network (requires 2 segmentation ID per chain), example with 2 chains -sharing the same 2 SRIOV ports (or PF): - -.. code-block:: bash - - flavor: - # Number of vCPUs for the flavor - vcpus: 4 - # Memory for the flavor in MB - ram: 8192 - # Size of local disk in GB - disk: 0 - extra_specs: - "hw:cpu_policy": dedicated - cores: 8 - sriov: true - internal_networks: - left: - segmentation_id: [3830, 3831] - physical_network: phys_sriov0 - right: - segmentation_id: [3832, 3833] - physical_network: phys_sriov1 - -Example of full run 2xPVP non-shared network SR-IOV: - -.. code-block:: bash - - 2018-12-04 17:15:25,284 INFO -c /tmp/nfvbench/sriov.yaml --rate 1Mpps --duration 1 -scc 2 --no-cleanup - 2018-12-04 17:15:25,287 INFO Connecting to TRex (127.0.0.1)... - 2018-12-04 17:15:25,463 INFO Connected to TRex - 2018-12-04 17:15:25,464 INFO Port 0: Ethernet Controller XL710 for 40GbE QSFP+ speed=40Gbps mac=3c:fd:fe:b5:3d:70 pci=0000:5e:00.0 driver=net_i40e - 2018-12-04 17:15:25,464 INFO Port 1: Ethernet Controller XL710 for 40GbE QSFP+ speed=40Gbps mac=3c:fd:fe:b5:3d:71 pci=0000:5e:00.1 driver=net_i40e - 2018-12-04 17:15:25,515 INFO Found built-in VM image file nfvbenchvm-0.6.qcow2 - 2018-12-04 17:15:26,457 INFO Created flavor 'nfvbench.medium' - 2018-12-04 17:15:27,449 INFO Created network: nfvbench-lnet0. - 2018-12-04 17:15:28,368 INFO Created network: nfvbench-rnet0. - 2018-12-04 17:15:29,143 INFO Created port nfvbench-loop-vm0-0 - 2018-12-04 17:15:29,626 INFO Security disabled on port nfvbench-loop-vm0-0 - 2018-12-04 17:15:30,636 INFO Created port nfvbench-loop-vm0-1 - 2018-12-04 17:15:31,139 INFO Security disabled on port nfvbench-loop-vm0-1 - 2018-12-04 17:15:31,140 INFO Creating instance nfvbench-loop-vm0 with AZ - 2018-12-04 17:15:34,893 INFO Created instance nfvbench-loop-vm0 - waiting for placement resolution... - 2018-12-04 17:15:35,068 INFO Waiting for instance nfvbench-loop-vm0 to become active (retry 1/101)... - <snip> - 2018-12-04 17:16:22,253 INFO Instance nfvbench-loop-vm0 is active and has been placed on nova:charter-compute-4 - 2018-12-04 17:16:23,154 INFO Created network: nfvbench-lnet1. - 2018-12-04 17:16:23,863 INFO Created network: nfvbench-rnet1. - 2018-12-04 17:16:24,799 INFO Created port nfvbench-loop-vm1-0 - 2018-12-04 17:16:25,267 INFO Security disabled on port nfvbench-loop-vm1-0 - 2018-12-04 17:16:26,006 INFO Created port nfvbench-loop-vm1-1 - 2018-12-04 17:16:26,612 INFO Security disabled on port nfvbench-loop-vm1-1 - 2018-12-04 17:16:26,612 INFO Creating instance nfvbench-loop-vm1 with AZ nova:charter-compute-4 - 2018-12-04 17:16:27,610 INFO Created instance nfvbench-loop-vm1 on nova:charter-compute-4 - 2018-12-04 17:16:27,610 INFO Instance nfvbench-loop-vm0 is ACTIVE on nova:charter-compute-4 - 2018-12-04 17:16:27,788 INFO Waiting for 1/2 instance to become active (retry 1/100)... - <snip> - - 2018-12-04 17:17:04,258 INFO Instance nfvbench-loop-vm1 is ACTIVE on nova:charter-compute-4 - 2018-12-04 17:17:04,258 INFO All instances are active - 2018-12-04 17:17:04,259 INFO Port 0: VLANs [3830, 3831] - 2018-12-04 17:17:04,259 INFO Port 1: VLANs [3832, 3833] - 2018-12-04 17:17:04,259 INFO Port 0: dst MAC ['fa:16:3e:ef:f4:b0', 'fa:16:3e:e5:74:cd'] - 2018-12-04 17:17:04,259 INFO Port 1: dst MAC ['fa:16:3e:d6:dc:84', 'fa:16:3e:8e:d9:30'] - 2018-12-04 17:17:04,259 INFO ChainRunner initialized - 2018-12-04 17:17:04,260 INFO Starting 2xPVP benchmark... - 2018-12-04 17:17:04,266 INFO Starting traffic generator to ensure end-to-end connectivity - 2018-12-04 17:17:04,297 INFO Created 2 traffic streams for port 0. - 2018-12-04 17:17:04,300 INFO Created 2 traffic streams for port 1. - 2018-12-04 17:17:04,420 INFO Captured unique src mac 0/4, capturing return packets (retry 1/100)... - 2018-12-04 17:17:06,532 INFO Received packet from mac: fa:16:3e:d6:dc:84 (chain=0, port=1) - 2018-12-04 17:17:06,532 INFO Received packet from mac: fa:16:3e:ef:f4:b0 (chain=0, port=0) - 2018-12-04 17:17:06,644 INFO Captured unique src mac 2/4, capturing return packets (retry 2/100)... - <snip> - - 2018-12-04 17:17:24,337 INFO Received packet from mac: fa:16:3e:8e:d9:30 (chain=1, port=1) - 2018-12-04 17:17:24,338 INFO Received packet from mac: fa:16:3e:e5:74:cd (chain=1, port=0) - 2018-12-04 17:17:24,338 INFO End-to-end connectivity established - 2018-12-04 17:17:24,355 INFO Cleared all existing streams - 2018-12-04 17:17:24,383 INFO Created 4 traffic streams for port 0. - 2018-12-04 17:17:24,386 INFO Created 4 traffic streams for port 1. - 2018-12-04 17:17:24,386 INFO Starting to generate traffic... - 2018-12-04 17:17:24,386 INFO Running traffic generator - 2018-12-04 17:17:25,415 INFO TX: 1000004; RX: 1000004; Est. Dropped: 0; Est. Drop rate: 0.0000% - 2018-12-04 17:17:25,415 INFO ...traffic generating ended. - 2018-12-04 17:17:25,420 INFO Service chain 'PVP' run completed. - 2018-12-04 17:17:25,471 INFO Clean up skipped. - 2018-12-04 17:17:25,508 INFO - ========== NFVBench Summary ========== - Date: 2018-12-04 17:17:04 - NFVBench version 3.0.3.dev1 - Openstack Neutron: - vSwitch: OPENVSWITCH - Encapsulation: VLAN - Benchmarks: - > Networks: - > Components: - > Traffic Generator: - Profile: trex-local - Tool: TRex - > Versions: - > Traffic_Generator: - build_date: Nov 13 2017 - version: v2.32 - built_by: hhaim - mode: STL - build_time: 10:58:17 - > CiscoVIM: 2.9.7-17036 - > Service chain: - > PVP: - > Traffic: - Profile: traffic_profile_64B - Bidirectional: True - Flow count: 10000 - Service chains count: 2 - Compute nodes: [u'nova:charter-compute-4'] - - Run Summary: - - +-----------------+-------------+----------------------+----------------------+----------------------+ - | L2 Frame Size | Drop Rate | Avg Latency (usec) | Min Latency (usec) | Max Latency (usec) | - +=================+=============+======================+======================+======================+ - | 64 | 0.0000% | 18 | 10 | 120 | - +-----------------+-------------+----------------------+----------------------+----------------------+ - - - L2 frame size: 64 - - Run Config: - - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - | Direction | Requested TX Rate (bps) | Actual TX Rate (bps) | RX Rate (bps) | Requested TX Rate (pps) | Actual TX Rate (pps) | RX Rate (pps) | - +=============+===========================+========================+=================+===========================+========================+=================+ - | Forward | 336.0000 Mbps | 336.0013 Mbps | 336.0013 Mbps | 500,000 pps | 500,002 pps | 500,002 pps | - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - | Reverse | 336.0000 Mbps | 336.0013 Mbps | 336.0013 Mbps | 500,000 pps | 500,002 pps | 500,002 pps | - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - | Total | 672.0000 Mbps | 672.0027 Mbps | 672.0027 Mbps | 1,000,000 pps | 1,000,004 pps | 1,000,004 pps | - +-------------+---------------------------+------------------------+-----------------+---------------------------+------------------------+-----------------+ - - Forward Chain Packet Counters and Latency: - - +---------+--------------+--------------+------------+------------+------------+ - | Chain | TRex.TX.p0 | TRex.RX.p1 | Avg lat. | Min lat. | Max lat. | - +=========+==============+==============+============+============+============+ - | 0 | 250,001 | 250,001 | 26 usec | 10 usec | 70 usec | - +---------+--------------+--------------+------------+------------+------------+ - | 1 | 250,001 | 250,001 | 11 usec | 10 usec | 39 usec | - +---------+--------------+--------------+------------+------------+------------+ - | total | 500,002 | 500,002 | 19 usec | 10 usec | 70 usec | - +---------+--------------+--------------+------------+------------+------------+ - - Reverse Chain Packet Counters and Latency: - - +---------+--------------+--------------+------------+------------+------------+ - | Chain | TRex.TX.p1 | TRex.RX.p0 | Avg lat. | Min lat. | Max lat. | - +=========+==============+==============+============+============+============+ - | 0 | 250,001 | 250,001 | 19 usec | 10 usec | 119 usec | - +---------+--------------+--------------+------------+------------+------------+ - | 1 | 250,001 | 250,001 | 19 usec | 10 usec | 120 usec | - +---------+--------------+--------------+------------+------------+------------+ - | total | 500,002 | 500,002 | 19 usec | 10 usec | 120 usec | - +---------+--------------+--------------+------------+------------+------------+ |
