aboutsummaryrefslogtreecommitdiffstats
path: root/docs/testing
diff options
context:
space:
mode:
authorMartin Klozik <martinx.klozik@intel.com>2017-06-02 13:56:57 +0100
committerMartin Klozik <martinx.klozik@intel.com>2017-08-04 09:54:47 +0100
commit6961a6fa333ca2cff055d7d7a889876263b673f5 (patch)
tree4e21c6bcf31b585411b9f201994a5e39675bca76 /docs/testing
parentd3b124a22bf3aa2c05a5cb030f37b97db3d27dbd (diff)
tests: L3, L4 and VxLAN tests for OVS & VPP
A set of tests was introduced with focus on L3, L4 and VxLAN performance of OVS and VPP. New testcases were created for phy2phy network scenario. In case of PVP and PVVP, only OVS testcases are available. Notes: * two sets of OVS P2P testcases were created, one creates unique flow for each IP address involved in the test (performance sensitive); Second set inserts just one flow with large network mask (tests with _mask suffix). * three different types of VPP P2P L3 testcases were created to demonstrate performance impact of multi ARP entries or IP routes. * VPP multi ARP record based testcases use a set of "workarounds" to load a large number of ARP entries. It is not possible to use "set ip arp count" syntax, as it doesn't work well for large count values (e.g. 60K) * OVS VxLAN testcases utilize existing OP2P deployment scenario and thus it can be used also with GRE and GENEVE tunnel types. Tunnel type to be used is defined by test configuration option "Tunnel Type". JIRA: VSPERF-518 Change-Id: I65adad976f12d8625d918a1996eb42693c511ee1 Signed-off-by: Martin Klozik <martinx.klozik@intel.com> Signed-off-by: Ciara Loftus <ciara.loftus@intel.com> Reviewed-by: Al Morton <acmorton@att.com> Reviewed-by: Christian Trautman <ctrautma@redhat.com> Reviewed-by: Sridhar Rao <sridhar.rao@spirent.com> Reviewed-by: Trevor Cooper <trevor.cooper@intel.com> Reviewed-by: Cian Ferriter <cian.ferriter@intel.com>
Diffstat (limited to 'docs/testing')
-rw-r--r--docs/testing/developer/design/vswitchperf_design.rst12
-rw-r--r--docs/testing/user/userguide/teststeps.rst37
2 files changed, 44 insertions, 5 deletions
diff --git a/docs/testing/developer/design/vswitchperf_design.rst b/docs/testing/developer/design/vswitchperf_design.rst
index a5a99c8a..8111b513 100644
--- a/docs/testing/developer/design/vswitchperf_design.rst
+++ b/docs/testing/developer/design/vswitchperf_design.rst
@@ -94,11 +94,13 @@ Configuration Procedure and Precedence
--------------------------------------
Configuration files follow a strict naming convention that allows them to be
-processed in a specific order. All the .conf files are named ``NN_name.conf``,
-where NN is a decimal number. The files are processed in order from 00_name.conf
-to 99_name.conf so that if the name setting is given in both a lower and higher
-numbered conf file then the higher numbered file is the effective setting as it
-is processed after the setting in the lower numbered file.
+processed in a specific order. All the .conf files are named ``NNx_name.conf``,
+where ``NN`` is a decimal number and ``x`` is an optional alphabetical suffix.
+The files are processed in order from ``00_name.conf`` to ``99_name.conf``
+(and from ``00a_name`` to ``00z_name``), so that if the name setting is given
+in both a lower and higher numbered conf file then the higher numbered file
+is the effective setting as it is processed after the setting in the lower
+numbered file.
The values in the file specified by ``--conf-file`` takes precedence over all
the other configuration files and does not have to follow the naming
diff --git a/docs/testing/user/userguide/teststeps.rst b/docs/testing/user/userguide/teststeps.rst
index 71f19714..5349d2ea 100644
--- a/docs/testing/user/userguide/teststeps.rst
+++ b/docs/testing/user/userguide/teststeps.rst
@@ -143,6 +143,43 @@ of supported objects and their most common functions follows:
['settings', 'setValue', 'GUEST_USERNAME', ['root']]
+ It is possible and more convenient to access any VSPERF configuration option directly
+ via ``$NAME`` notation. Option evaluation is done during runtime and vsperf will
+ automatically translate it to the appropriate call of ``settings.getValue``.
+ If the referred parameter does not exist, then vsperf will keep ``$NAME``
+ string untouched and it will continue with testcase execution. The reason is to
+ avoid test execution failure in case that ``$`` sign has been used from different
+ reason than vsperf parameter evaluation.
+
+ **NOTE:** It is recommended to use ``${NAME}`` notation for any shell parameters
+ used within ``Exec_Shell`` call to avoid a clash with configuration parameter
+ evaluation.
+
+ **NOTE:** It is possible to refer to vsperf parameter value by ``#PARAM()`` macro
+ (see :ref:`overriding-parameters-documentation`. However ``#PARAM()`` macro is
+ evaluated at the beginning of vsperf execution and it will not reflect any changes
+ made to the vsperf configuration during runtime. On the other hand ``$NAME``
+ notation is evaluated during test execution and thus it contains any modifications
+ to the configuration parameter made by vsperf (e.g. ``TOOLS`` and ``NICS``
+ dictionaries) or by testcase definition (e.g. ``TRAFFIC`` dictionary).
+
+ Examples:
+
+ .. code-block:: python
+
+ ['tools', 'exec_shell', "$TOOLS['ovs-vsctl'] show"]
+
+ ['settings', 'setValue', 'TRAFFICGEN_IXIA_PORT2', '$TRAFFICGEN_IXIA_PORT1'],
+
+ ['vswitch', 'add_flow', 'int_br0',
+ {'in_port': '#STEP[1][1]',
+ 'dl_type': '0x800',
+ 'nw_proto': '17',
+ 'nw_dst': '$TRAFFIC["l3"]["dstip"]/8',
+ 'actions': ['output:#STEP[2][1]']
+ }
+ ]
+
* ``namespace`` - creates or modifies network namespaces
List of supported functions: