summaryrefslogtreecommitdiffstats
path: root/docs/development
diff options
context:
space:
mode:
authorahothan <ahothan@cisco.com>2018-11-13 10:16:15 -0800
committerahothan <ahothan@cisco.com>2018-11-13 10:16:15 -0800
commit7a90e74a1390794b72fc5c3629e141f2def908d7 (patch)
treedef2805186b2a2f65ac7db183b3ce576734bc05a /docs/development
parent3dfb5268ebfada08c1a2316708564e627f86da42 (diff)
Update 2.0 doc
Change-Id: I223bd40e798c772d7cf7423d88f62bccb164a46b Signed-off-by: ahothan <ahothan@cisco.com>
Diffstat (limited to 'docs/development')
-rw-r--r--docs/development/design/design.rst17
-rw-r--r--docs/development/design/traffic_desc.rst7
-rw-r--r--docs/development/design/versioning.rst2
-rw-r--r--docs/development/overview/overview.rst4
4 files changed, 18 insertions, 12 deletions
diff --git a/docs/development/design/design.rst b/docs/development/design/design.rst
index 6de6007..75b90f8 100644
--- a/docs/development/design/design.rst
+++ b/docs/development/design/design.rst
@@ -15,9 +15,11 @@ Introduction
NFVbench can be decomposed in the following components:
- Configuration
-- Staging
-- Traffic generation
-- Traffic generator results analysis
+- Orchestration:
+
+ - Staging
+ - Traffic generation
+ - Results analysis
Configuration
-------------
@@ -34,7 +36,7 @@ User configuration can come from:
- custom platform pluging
The precedence order for configuration is (from highest precedence to lowest precedence)
-- CLI confguration or REST configuration
+- CLI configuration or REST configuration
- custom platform plugin
- default configuration
@@ -43,6 +45,11 @@ with default platform options which can be either hardcoded or calculated at run
(such as platform deployment configuration files).
A custom platform plugin class is a child of the parent class nfvbench.config_plugin.ConfigPlugin.
+Orchestration
+-------------
+Once the configuration is settled, benchmark orchestration is managed by the ChainRunner class (nfvbench.chain_runner.ChainRunner).
+The chain runner will take care of orchestrating the staging, traffic generation and results analysis.
+
Staging
-------
@@ -57,7 +64,7 @@ Traffic Generation
The traffic generation component is in charge of contrilling the TRex traffic generator using its python API.
It includes tasks such as:
- traffic check end to end to make sure the packet path is clear in both directions before starting a benchmark
-- programming the Trex traffic flows based on requested parameters
+- programming the TRex traffic flows based on requested parameters
- fixed rate control
- NDR/PDR binary search
diff --git a/docs/development/design/traffic_desc.rst b/docs/development/design/traffic_desc.rst
index 2a40b6a..6442013 100644
--- a/docs/development/design/traffic_desc.rst
+++ b/docs/development/design/traffic_desc.rst
@@ -10,11 +10,10 @@ The general packet path model followed by NFVbench requires injecting traffic in
number of service chains, where each service chain is identified by 2 edge networks (left and right).
In the current multi-chaining model:
-- all service chains share the same left and right edge networks
-- each port associated to the traffic generator is dedicated to send traffic to one edge network
+- all service chains can either share the same left and right edge networks or can have their own edge networks
+- each port associated to the traffic generator is dedicated to send traffic to one side of the edge networks
-In an OpenStack deployment, this corresponds to all chains sharing the same 2 neutron networks.
-If VLAN encapsulation is used, all traffic sent to a port will have the same VLAN id.
+If VLAN encapsulation is used, all traffic sent to a port will either have the same VLAN id (shared networks) or distinct VLAN ids (dedicated egde networks)
Basic Packet Description
------------------------
diff --git a/docs/development/design/versioning.rst b/docs/development/design/versioning.rst
index 8103534..40e70f2 100644
--- a/docs/development/design/versioning.rst
+++ b/docs/development/design/versioning.rst
@@ -13,4 +13,4 @@ These git tags are applied indepently of the OPNFV release tags which are applie
In general it is recommeneded to always have a project git version tag associated to any OPNFV release tag content obtained from a sync from master.
-NFVbench Docker containers will be versioned based on the OPNF release tags or based on NFVbench project tags.
+NFVbench Docker containers will be versioned based on the NFVbench project tags.
diff --git a/docs/development/overview/overview.rst b/docs/development/overview/overview.rst
index 792d50f..26e19d1 100644
--- a/docs/development/overview/overview.rst
+++ b/docs/development/overview/overview.rst
@@ -12,10 +12,10 @@ Introduction
NFVbench is a python application that is designed to run in a compact and portable format inside a container and on production pods.
As such it only uses open sourec software with minimal hardware requirements (just a NIC card that is DPDK compatible).
Traffic generation is handled by TRex on 2 physical ports (2x10G or higher) forming traffic loops up to VNF level and following
-a path that is common to all NFV applications: external source to top of rack switch(es) to conpute node(s) to vswitch (if applicable)
+a path that is common to all NFV applications: external source to top of rack switch(es) to compute node(s) to vswitch (if applicable)
to VNF(s) and back.
-Configuration of benchmarks is through a hierarchy of yaml configuraton files and command line arguments.
+Configuration of benchmarks is through a yaml configuraton file and command line arguments.
Results are available in different formats:
- text output with tabular results