connections: Introduction of generic API

Redesign of vSwitch and vSwitch controller classes, to use generic
connection methods for configuration of vSwitch. This API
is more generic and vSwitch agnostic, thus deployment scenarios like
P2P, PVP, PVVP (i.e. PVVPx) can be used for all (currently)
supported vSwitches. Usage of new API will simplify an introduction
of new vSwitches in the future.

This patchset introduces following changes:
* OVS: implementation of add_, del_, dump_ connection(s) and their
  validation methods
* VPP: bidir parameter removed - it is up to the deployment scenario
  implementation to take care about bidirectional connections
* P2P and PXP controllers were updated to use connection methods
  instead of flow related methods. Thus standard TCs will support
  both OVS and VPP. NOTE, PVPV is not supported for VPP (yet?).
* refactoring of vSwitch interfaces and inherited classes
* VPP step driven TCs were replaced by standard TCs with appropriate
  deployment scenarios. This is for backward compatibility with
  TC reporting. Once reporting of VPP TC results into results DB will be
  modified, this TCs can be removed.
* OVS routing tables support was generalized to support P2P and
  PXP deployments and step driven TCs. Usage of OVS routing tables
  is now configurable (turned off by default) for better comparison of
  results among various vSwitches.
* Multistream pre_installed_flows feature was generalized to
  support P2P and PXP deployments and step driven TCs.
* IxNet: TRAFFIC['l4']['dstport'] will be used as a start value for port
  iteration if L4 multistream feature is enabled.
* OVS: default flow template is now configurable via OVS_FLOW_TEMPLATE
* OVS: support of TRAFFIC['flow_type']='ip' was generalized to work
  with connection methods (i.e. with P2P and PXP deployments and
  step driven TCs)
* integration TCs: modification of integration TCs and their macros to
  utilize new generic connection based API
* CI: list of TCs for VERIFY & MERGE jobs was changed to run
  the same generic tests for both OVS & VPP
* documentation update
* small fixes and improvements

JIRA: VSPERF-579

Change-Id: If4e6e6037929eab9f16c2bbcb8a0fb30e5d6f9b0
Signed-off-by: Martin Klozik <martin.klozik@tieto.com>
Reviewed-by: Richard Elias <richard.elias@tieto.com>
Reviewed-by: Al Morton <acmorton@att.com>
Reviewed-by: Christian Trautman <ctrautma@redhat.com>
Reviewed-by: Sridhar Rao <sridhar.rao@spirent.com>

1 files changed, 12 insertions, 2 deletions

diff --git a/docs/testing/developer/devguide/design/vswitchperf_design.rst b/docs/testing/developer/devguide/design/vswitchperf_design.rst
index 7fbde886..b8a3ba19 100644
--- a/docs/testing/developer/devguide/design/vswitchperf_design.rst
+++ b/docs/testing/developer/devguide/design/vswitchperf_design.rst
@@ -1,6 +1,6 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. (c) OPNFV, Intel Corporation, AT&T and others.
+.. (c) OPNFV, Intel Corporation, AT&T, Tieto and others.
 
 .. _vsperf-design:
 
@@ -332,7 +332,6 @@ Detailed description of ``TRAFFIC`` dictionary items follows:
                       feature. If enabled, it will implicitly insert a flow
                       for each stream. If multistream is disabled, then
                       pre-installed flows will be ignored.
-                      Note: It is supported only for p2p deployment scenario.
                       Data type: str
                       Supported values:
                          "Yes" - flows will be inserted into OVS
@@ -777,6 +776,13 @@ As it is able to forward traffic between multiple VM NIC pairs.
 Note: In case of ``linux_bridge``, all NICs are connected to the same
 bridge inside the VM.
 
+Note: In case that multistream feature is configured and ``pre_installed_flows``
+is set to ``Yes``, then stream specific flows will be inserted only for connections
+originating at physical ports. The rest of the flows will be based on port
+numbers only. The same logic applies in case that ``flow_type`` TRAFFIC option
+is set to ``ip``. This configuration will avoid a testcase malfunction if frame headers
+are modified inside VM (e.g. MAC swap or IP change).
+
 VM, vSwitch, Traffic Generator Independence
 ===========================================
 
@@ -912,6 +918,10 @@ Vsperf uses a standard set of routing tables in order to allow tests to easily
 mix and match Deployment Scenarios (PVP, P2P topology), Tuple Matching and
 Frame Modification requirements.
 
+The usage of routing tables is driven by configuration parameter ``OVS_ROUTING_TABLES``.
+Routing tables are disabled by default (i.e. parameter is set to ``False``) for better
+comparison of results among supported vSwitches (e.g. OVS vs. VPP).
+
 .. code-block:: console
 
       +--------------+