summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/development/design/index.rst1
-rw-r--r--docs/development/design/ndrpdr.rst51
-rw-r--r--docs/development/design/traffic_desc.rst85
-rw-r--r--docs/release/release-notes/release-notes.rst24
-rw-r--r--docs/testing/user/userguide/advanced.rst86
-rw-r--r--docs/testing/user/userguide/quickstart_docker.rst2
-rw-r--r--docs/testing/user/userguide/readme.rst25
7 files changed, 225 insertions, 49 deletions
diff --git a/docs/development/design/index.rst b/docs/development/design/index.rst
index c54888a..0500ca2 100644
--- a/docs/development/design/index.rst
+++ b/docs/development/design/index.rst
@@ -12,4 +12,5 @@ OPNFV NFVbench Euphrates Design
design
versioning
+ traffic_desc
ndrpdr
diff --git a/docs/development/design/ndrpdr.rst b/docs/development/design/ndrpdr.rst
index 5361174..e34e8ba 100644
--- a/docs/development/design/ndrpdr.rst
+++ b/docs/development/design/ndrpdr.rst
@@ -6,11 +6,15 @@
NDR/PDR Binary Search
=====================
+The NDR/PDR binary search algorithm used by NFVbench is based on the algorithm used by the
+FD.io CSIT project, with some additional optimizations.
+
Algorithm Outline
-----------------
-The ServiceChain class is responsible for calculating the NDR/PDR for all frame sizes requested in the configuration.
-Calculation for 1 frame size is delegated to the TrafficClient class.
+The ServiceChain class (nfvbench/service_chain.py) is responsible for calculating the NDR/PDR
+or all frame sizes requested in the configuration.
+Calculation for 1 frame size is delegated to the TrafficClient class (nfvbench/traffic_client.py)
Call chain for calculating the NDR-PDR for a list of frame sizes:
@@ -22,23 +26,58 @@ Call chain for calculating the NDR-PDR for a list of frame sizes:
- TrafficClient.__range_search() recursive binary search
The search range is delimited by a left and right rate (expressed as a % of line rate per direction).
+The search always start at line rate per port, e.g. in the case of 2x10Gbps, the first iteration
+will send 10Gbps of traffic on each port.
The load_epsilon configuration parameter defines the accuracy of the result as a % of line rate.
The default value of 0.1 indicates for example that the measured NDR and PDR are within 0.1% of line rate of the
actual NDR/PDR (e.g. 0.1% of 10Gbps is 10Mbps). It also determines how small the search range must be in the binary search.
+Smaller values of load_epsilon will result in more iterations and will take more time but may not
+always be beneficial if the absolute value falls below the precision level of the measurement.
+For example a value of 0.01% would translate to an absolute value of 1Mbps (for a 10Gbps port) or
+around 10kpps (at 64 byte size) which might be too fine grain.
The recursion narrows down the range by half and stops when:
- the range is smaller than the configured load_epsilon value
- or when the search hits 100% or 0% of line rate
+Optimization
+------------
+
+Binary search algorithms assume that the drop rate curve is monotonically increasing with the Tx rate.
+To save time, the algorithm used by NFVbench is capable of calculating the optimal Tx rate for an
+arbitrary list of target maximum drop rates in one pass instead of the usual 1 pass per target maximum drop rate.
+This saves time linearly to the number target drop rates.
+For example, a typical NDR/PDR search will have 2 target maximum drop rates:
+
+- NDR = 0.001%
+- PDR = 0.1%
+
+The binary search will then start with a sorted list of 2 target drop rates: [0.1, 0.001].
+The first part of the binary search will then focus on finding the optimal rate for the first target
+drop rate (0.1%). When found, the current target drop rate is removed from the list and
+iteration continues with the next target drop rate in the list but this time
+starting from the upper/lower range of the previous target drop rate, which saves significant time.
+The binary search continues until the target maximum drop rate list is empty.
+
+Results Granularity
+-------------------
+The binary search results contain per direction stats (forward and reverse).
+In the case of multi-chaining, results contain per chain stats.
+The current code only reports aggregated stats (forward + reverse for all chains) but could be enhanced
+to report per chain stats.
+
+
+CPU Limitations
+---------------
One particularity of using a software traffic generator is that the requested Tx rate may not always be met due to
resource limitations (e.g. CPU is not fast enough to generate a very high load). The algorithm should take this into
consideration:
-- always monitor the actual Tx rate achieved
+- always monitor the actual Tx rate achieved as reported back by the traffic generator
- actual Tx rate is always <= requested Tx rate
- the measured drop rate should always be relative to the actual Tx rate
-- if the actual Tx rate is < requested Tx rate and the measured drop rate is already within threshold (<NDR/PDR threshold) then the binary search must stop with proper warning
-
-
+- if the actual Tx rate is < requested Tx rate and the measured drop rate is already within threshold
+ (<NDR/PDR threshold) then the binary search must stop with proper warning because the actual NDR/PDR
+ might probably be higher than the reported values
diff --git a/docs/development/design/traffic_desc.rst b/docs/development/design/traffic_desc.rst
new file mode 100644
index 0000000..2a40b6a
--- /dev/null
+++ b/docs/development/design/traffic_desc.rst
@@ -0,0 +1,85 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International
+.. License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) Cisco Systems, Inc
+
+Traffic Description
+===================
+
+The general packet path model followed by NFVbench requires injecting traffic into an arbitrary
+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
+
+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.
+
+Basic Packet Description
+------------------------
+
+The code to create the UDP packet is located in TRex.create_pkt() (nfvbench/traffic_gen/trex.py).
+
+NFVbench always generates UDP packets (even when doing L2 forwarding).
+The final size of the frame containing each UDP packet will be based on the requested L2 frame size.
+When taking into account the minimum payload size requirements from the traffic generator for
+the latency streams, the minimum L2 frame size is 64 byte (no vlan tagging) or
+68 bytes (with vlan tagging).
+
+Flows Specification
+-------------------
+
+Mac Addresses
+.............
+The source MAC address is always the local port MAC address (for each port).
+The destination MAC address is based on the configuration and can be:
+
+- the traffic generator peer port MAC address in the case of L2 loopback at the switch level
+ or when using a loopback cable
+- the dest MAC as specified by the configuration file (EXT chain no ARP)
+- the dest MAC as discovered by ARP (EXT chain)
+- the VM MAC as dicovered from Neutron API (PVP, PVVP chains)
+
+NFVbench does not currently range on the MAC addresses.
+
+IP addresses
+............
+The source IP address is fixed per chain.
+The destination IP address is variable within a distinct range per chain.
+
+UDP ports
+.........
+The source and destination ports are fixed for all packets and can be set in the configuratoon
+file (default is 53).
+
+Payload User Data
+.................
+The length of the user data is based on the requested L2 frame size and takes into account the
+size of the L2 header - including the VLAN tag if applicable.
+
+
+IMIX Support
+------------
+In the case of IMIX, each direction is made of 4 streams:
+- 1 latency stream
+- 1 stream for each IMIX frame size
+
+The IMIX ratio is encoded into the number of consecutive packets sent by each stream in turn.
+
+Service Chains and Streams
+--------------------------
+A stream identifies one "stream" of packets with same characteristics such as rate and destination address.
+NFVbench will create 2 streams per service chain per direction:
+
+- 1 latency stream set to 1000pps
+- 1 main traffic stream set to the requested Tx rate less the latency stream rate (1000pps)
+
+For example, a benchmark with 1 chain (fixed rate) will result in a total of 4 streams.
+A benchmark with 20 chains will results in a total of 80 streams (fixed rate, it is more with IMIX).
+
+The overall flows are split equally between the number of chains by using the appropriate destination
+MAC address.
+
+For example, in the case of 10 chains, 1M flows and fixed rate, there will be a total of 40 streams.
+Each of the 20 non-latency stream will generate packets corresponding to 50,000 flows (unique src/dest address tuples).
diff --git a/docs/release/release-notes/release-notes.rst b/docs/release/release-notes/release-notes.rst
index a3402cb..7c9cbcb 100644
--- a/docs/release/release-notes/release-notes.rst
+++ b/docs/release/release-notes/release-notes.rst
@@ -2,6 +2,30 @@
.. http://creativecommons.org/licenses/by/4.0
.. (c) Cisco Systems, Inc
+RELEASE NOTES
++++++++++++++
+
+OPNFV Fraser Release
+====================
+
+Over 30 Jira tickets have been addressed in this release (Jira NFVBENCH-55 to NFVBENCH-78)
+
+The Fraser release adds the following new features:
+
+- support for benchmarking non-OpenStack environments (with external setup and no OpenStack openrc file)
+- PVVP packet path with SRIOV at the edge and vswitch between VMs
+- support logging events and results through fluentd
+
+Enhancements and main bug fixes:
+
+- end to end connectivity for larger chain count is now much more accurate for large chain count - avoiding excessive drops
+- use newer version of TRex (2.32)
+- use newer version of testpmd DPDK
+- NDR/PDR uses actual TX rate to calculate drops - resulting in more accurate results
+- add pylint to unit testing
+- add self sufficient and standalone unit testing (without actual testbed)
+
+
OPNFV Euphrates Release
=======================
diff --git a/docs/testing/user/userguide/advanced.rst b/docs/testing/user/userguide/advanced.rst
index 252cbc9..02c7fce 100644
--- a/docs/testing/user/userguide/advanced.rst
+++ b/docs/testing/user/userguide/advanced.rst
@@ -314,46 +314,60 @@ 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.
-Cleanup Script
---------------
+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
-The nfvbench_cleanup script will cleanup resources created by NFVbench. You need to pass the OpenStack RC file in order to connect to
-OpenStack.
+ # 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
- Discovering Storage resources...
- Discovering Compute resources...
- Discovering Network resources...
- Discovering Keystone resources...
-
- SELECTED RESOURCES:
- +-----------+-------------------+--------------------------------------+
- | Type | Name | UUID |
- |-----------+-------------------+--------------------------------------|
- | flavors | nfvbench.medium | 362b2215-89d1-4f46-8b89-8e58165ff5bc |
- | instances | nfvbench-loop-vm0 | f78dfb74-1b8e-4c5c-8d83-652a7571da95 |
- | networks | nfvbench-net0 | 57d7e6c9-325f-4c13-9b1b-929344cc9c39 |
- | networks | nfvbench-net1 | 2d429bcd-33fa-4aa4-9f2e-299a735177c9 |
- +-----------+-------------------+--------------------------------------+
-
- Warning: You didn't specify a resource list file as the input. The script will delete all resources shown above.
+ # 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
- *** STORAGE cleanup
- *** COMPUTE cleanup
- . Waiting for 1 instances to be fully deleted...
- . INSTANCE 1 left to be deleted, retries left=5...
- . INSTANCE 1 left to be deleted, retries left=4...
- + INSTANCE nfvbench-loop-vm0 is successfully deleted
- + FLAVOR nfvbench.medium is successfully deleted
- *** NETWORK cleanup
- + Network port 075d91f3-fa6a-428c-bd3f-ebd40cd935e1 is successfully deleted
- + Network port 3a7ccd8c-53a6-43d0-a823-4b5ca762d06e is successfully deleted
- + NETWORK nfvbench-net0 is successfully deleted
- + Network port 5b5a75bd-e0b5-4f81-91b9-9e216d194f48 is successfully deleted
- + Network port cc2d8f1b-49fe-491e-9e44-6990fc57e891 is successfully deleted
- + NETWORK nfvbench-net1 is successfully deleted
- *** KEYSTONE cleanup
+ 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/quickstart_docker.rst b/docs/testing/user/userguide/quickstart_docker.rst
index c5e5eda..a5152cf 100644
--- a/docs/testing/user/userguide/quickstart_docker.rst
+++ b/docs/testing/user/userguide/quickstart_docker.rst
@@ -115,7 +115,7 @@ To run NFVBench enabling REST server (mount the configuration json and the path
.. 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
+ 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:
diff --git a/docs/testing/user/userguide/readme.rst b/docs/testing/user/userguide/readme.rst
index 785ffed..b437ff9 100644
--- a/docs/testing/user/userguide/readme.rst
+++ b/docs/testing/user/userguide/readme.rst
@@ -46,11 +46,21 @@ main purpose is to measure the performance of the NFVi infrastructure which is m
External Chains
---------------
-NFVbench also supports settings that involve externally staged packet paths with or without OpenStack:
+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
------------------
@@ -116,7 +126,8 @@ 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).
+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:
@@ -126,6 +137,8 @@ This innovative feature will allow to measure easily the performance of a fully
Multi-chaining is currently limited to 1 compute node (PVP or PVVP intra-node) or 2 compute nodes (for PVVP inter-node).
The 2 edge interfaces for all service chains will share the same 2 networks.
+The total traffic will be split equally across all chains.
+
SR-IOV
^^^^^^
@@ -179,7 +192,7 @@ NFVbench is agnostic of the virtual switch implementation and has been tested wi
-
-
-
-
+Limitations
+***********
+NFVbench only supports VLAN with OpenStack.
+NFVbench does not support VxLAN overlays.