From 7a90e74a1390794b72fc5c3629e141f2def908d7 Mon Sep 17 00:00:00 2001 From: ahothan Date: Tue, 13 Nov 2018 10:16:15 -0800 Subject: Update 2.0 doc Change-Id: I223bd40e798c772d7cf7423d88f62bccb164a46b Signed-off-by: ahothan --- docs/development/design/design.rst | 17 ++++++++++++----- docs/development/design/traffic_desc.rst | 7 +++---- docs/development/design/versioning.rst | 2 +- docs/development/overview/overview.rst | 4 ++-- 4 files changed, 18 insertions(+), 12 deletions(-) (limited to 'docs/development') 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 -- cgit 1.2.3-korg