summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/development/design/design.rst4
-rw-r--r--docs/release/release-notes/release-notes.rst53
-rw-r--r--docs/testing/user/userguide/faq.rst9
-rw-r--r--docs/testing/user/userguide/hw_requirements.rst2
-rw-r--r--docs/testing/user/userguide/quickstart_docker.rst9
-rw-r--r--docs/testing/user/userguide/server.rst37
6 files changed, 64 insertions, 50 deletions
diff --git a/docs/development/design/design.rst b/docs/development/design/design.rst
index d0f2f45..6de6007 100644
--- a/docs/development/design/design.rst
+++ b/docs/development/design/design.rst
@@ -50,7 +50,7 @@ The staging component is in charge of staging the OpenStack resources that are u
For example, for a PVP packet path, this module will create 2 Neutron networks and one VM instance connected to these 2 networks.
Multi-chaining and VM placement is also handled by this module.
-Main class: nfvbench.chain_managers.StageManager
+Main class: nfvbench.chaining.ChainManager
Traffic Generation
------------------
@@ -70,4 +70,4 @@ At the end of a traffic generation session, this component collects the results
is suitable for the various output formats (JSON, REST, file, fluentd).
In the case of multi-chaining, it handles aggregation of results across chains.
-Main class: nfvbench.chain_managers.StatsManager
+Main class: nfvbench.stats_manager.StatsManager
diff --git a/docs/release/release-notes/release-notes.rst b/docs/release/release-notes/release-notes.rst
index 7c9cbcb..655559d 100644
--- a/docs/release/release-notes/release-notes.rst
+++ b/docs/release/release-notes/release-notes.rst
@@ -5,6 +5,52 @@
RELEASE NOTES
+++++++++++++
+Release 2.0
+===========
+Major release highlights:
+
+- Dedicated chain networks
+- VxLAN support with VTEP in the traffic generator
+- Enhanced chain analysis
+- Code refactoring and enhanced unit testing
+- Miscellaneous enhancement
+
+Dedicated chain networks
+------------------------
+NFVbench 1.x only supported shared networks across chains.
+For example, 20xPVP would create only 2 networks (left and right) shared by all chains.
+With NFVbench 2.0, chain networks will become dedicated (unshared) by default with an option in
+the nfvbench configuration to shared them. A 20xPVP run will create 2x20 networks instead.
+
+Enhanced chain analysis
+-----------------------
+The new chain analysis improves at multiple levels:
+
+- there is now one table for each direction (forward and reverse) that both read from left to right
+- per-chain packet counters and latency
+- all-chain aggregate packet counters and latency
+- supports both shared and dedicated chain networks
+
+Code refactoring and enhanced unit testing
+------------------------------------------
+The overall code structure is now better partitioned in the following functions:
+
+- staging and resource discovery
+- traffic generator
+- stats collection
+
+The staging algorithm was rewritten to be:
+
+- a lot more robust to errors and to handle better resource reuse use cases.
+ For example when a network with a matching name is discovered the new code will verify that the
+ network is associated to the right VM instance
+- a lot more strict when it comes to the inventory of MAC addresses. For example the association
+ from each VM MAC to a chain index for each Trex port is handled in a much more strict manner.
+
+Although not all code is unit tested, the most critical parts are unit tested with the use of
+the mock library. The resulting unit test code can run in isolation without needing a real system under test.
+
+
OPNFV Fraser Release
====================
@@ -55,10 +101,3 @@ This is the introductory release for NFVbench. In this release, NFVbench provide
- detailed results in JSON format
- summary tabular results
- can send logs and results to one or more fluentd aggregators (per configuration)
-
-
-
-
-
-
-
diff --git a/docs/testing/user/userguide/faq.rst b/docs/testing/user/userguide/faq.rst
index 7daa8c9..9da2e90 100644
--- a/docs/testing/user/userguide/faq.rst
+++ b/docs/testing/user/userguide/faq.rst
@@ -8,13 +8,19 @@ 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?
-----------------------------------------------
-That is possible but you will not be able to run more advanced use cases such as PVVP inter-node which requires 2 compute nodes.
+Yes.
Can I drive NFVbench using a REST interface?
--------------------------------------------
@@ -41,4 +47,3 @@ The most common issues that prevent traffic from passing are:
- 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/hw_requirements.rst b/docs/testing/user/userguide/hw_requirements.rst
index 1ebb19e..4fc6e21 100644
--- a/docs/testing/user/userguide/hw_requirements.rst
+++ b/docs/testing/user/userguide/hw_requirements.rst
@@ -30,7 +30,7 @@ The 2 corresponding ports on the switch(es) facing the Trex ports on the Linux s
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 (although that will limit some of the features that invove multiple compute nodes in the packet path).
+a compute node without a switch.
Software Requirements
---------------------
diff --git a/docs/testing/user/userguide/quickstart_docker.rst b/docs/testing/user/userguide/quickstart_docker.rst
index a5152cf..625e491 100644
--- a/docs/testing/user/userguide/quickstart_docker.rst
+++ b/docs/testing/user/userguide/quickstart_docker.rst
@@ -40,7 +40,7 @@ The NFVbench container requires the following Docker options to operate properly
| | /tmp/nfvbench director in the container but any |
| | other similar mapping can work as well |
+-------------------------------------------------------+-------------------------------------------------------+
-| --net=host | (optional) needed if you run the NFVbench ok |
+| --net=host | (optional) needed if you run the NFVbench |
| | server in the container (or use any appropriate |
| | docker network mode other than "host") |
+-------------------------------------------------------+-------------------------------------------------------+
@@ -79,7 +79,7 @@ the 2 NIC ports to use for generating traffic have the PCI addresses "04:00.0" a
"port": 1,
}
],
- "intf_speed": "10Gbps",
+ "intf_speed": "",
"ip": "127.0.0.1",
"name": "trex-local",
"software_mode": false,
@@ -156,7 +156,7 @@ Create a new file containing the minimal configuration for NFVbench, we can call
- port: 1
switch_port:
pci:
- intf_speed: 10Gbps
+ intf_speed:
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).
@@ -192,7 +192,7 @@ PCI addresses "0a:00.0" and "0a:00.1" (first 2 ports of the quad port NIC):
- port: 1
switch_port:
pci: "0a:00.1"
- intf_speed: 10Gbps
+ intf_speed:
.. warning::
@@ -238,4 +238,3 @@ When no longer needed, the container can be terminated using the usual docker co
docker kill nfvbench
docker rm nfvbench
-
diff --git a/docs/testing/user/userguide/server.rst b/docs/testing/user/userguide/server.rst
index 70c5fdd..921e3bc 100644
--- a/docs/testing/user/userguide/server.rst
+++ b/docs/testing/user/userguide/server.rst
@@ -44,7 +44,7 @@ HTTP Interface
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:
+Example request:
.. code-block:: bash
@@ -219,30 +219,13 @@ The entire default configuration can be viewed using the --show-json-config opti
},
"name": "(built-in default config)",
"no_cleanup": false,
- "no_int_config": false,
- "no_reset": false,
- "no_tor_access": false,
"no_traffic": false,
- "no_vswitch_access": false,
"openrc_file": "/tmp/nfvbench/openstack/openrc",
- "openstack_defaults": "/tmp/nfvbench/openstack/defaults.yaml",
- "openstack_setup": "/tmp/nfvbench/openstack/setup_data.yaml",
"rate": "ndr_pdr",
"service_chain": "PVP",
"service_chain_count": 1,
"sriov": false,
"std_json": null,
- "tor": {
- "switches": [
- {
- "host": "172.26.233.12",
- "password": "lab",
- "port": 22,
- "username": "admin"
- }
- ],
- "type": "N9K"
- },
"traffic": {
"bidirectional": true,
"profile": "traffic_profile_64B"
@@ -271,7 +254,7 @@ The entire default configuration can be viewed using the --show-json-config opti
"vlan": null
}
],
- "intf_speed": "10Gbps",
+ "intf_speed": null,
"ip": "127.0.0.1",
"name": "trex-local",
"tool": "TRex"
@@ -324,12 +307,6 @@ The entire default configuration can be viewed using the --show-json-config opti
],
"unidir_reverse_traffic_pps": 1,
"vlan_tagging": true,
- "vts_ncs": {
- "host": null,
- "password": "secret",
- "port": 22,
- "username": "admin"
- }
}
@@ -445,7 +422,8 @@ use the default NFVbench configuration but do not generate traffic (no_traffic p
{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'vts_ncs': {u'username': u'admin', u'host': None, u'password': u'secret', u'port': 22}, 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'10Gbps', u'interfaces': [{u'pci': u'0a:00.0', u'port': 0, u'vlan': 1998, u'switch_port': None},
+ 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},
...
@@ -458,10 +436,3 @@ Example of invocation using Websocket/SocketIO, execute NFVbench using the defau
.. 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
-
-
-
-
-
-
-