Merge "tests: L3, L4 and VxLAN tests for OVS & VPP"

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: