[NFVBENCH-58] Add option to specify dest MAC with EXT CHAIN when ARP is

[nfvbench.git] / nfvbench / cfg.default.yaml

diff --git a/nfvbench/cfg.default.yaml b/nfvbench/cfg.default.yaml
old mode 100644 (file)
new mode 100755 (executable)
index a8bdc2b..e1c05c3
--- a/nfvbench/cfg.default.yaml
+++ b/nfvbench/cfg.default.yaml
@@ -18,6 +18,13 @@
 # Fields that can be over-ridden at the command line are marked with the corresponding
 # option, e.g. "--interval"
 
+# The OpenStack openrc file to use (must be a valid full pathname). If running
+# in a container, this path must be valid in the container.
+#
+# The only case where this field can be empty is when measuring a system that does not run
+# OpenStack or when OpenStack APIs are not accessible or OpenStack APis use is not
+# desirable. In that case the EXT service chain must be used.
+openrc_file:
 
 # Forwarder to use in nfvbenchvm image. Available options: ['vpp', 'testpmd']
 vm_forwarder: testpmd
@@ -149,6 +156,15 @@ traffic_generator:
     # `gateway_ip_addrs_step`: step for generating router gateway sequences. default is 0.0.0.1
     # `udp_src_port`: the source port for sending UDP traffic, default is picked by TRex (53)
     # `udp_dst_port`: the destination port for sending UDP traffic, default is picked by TRex (53)
+    # `mac_addrs_left` & `mac_addrs_right`: Lists of MAC addresses corresponding to the number of chains
+    # specified for `service_chain_count`.
+    #   - If both lists are empty the far end MAC of the traffic generator will be used for left and right
+    #   - The MAC addresses will only be used when `service_chain` is EXT and `no_arp` is true.
+    #   - The length of each list must match the number of chains being used.
+    #   - The index of each list must correspond to the chain index to ensure proper pairing.
+    #   - Below is an example of using two chains:
+    #     - mac_addrs_left: ['00:00:00:00:01:00', '00:00:00:00:02:00']
+    #     - mac_addrs_right: ['00:00:00:00:01:01', '00:00:00:00:02:01']
     ip_addrs: ['10.0.0.0/8', '20.0.0.0/8']
     ip_addrs_step: 0.0.0.1
     tg_gateway_ip_addrs: ['1.1.0.100', '2.2.0.100']
@@ -157,6 +173,8 @@ traffic_generator:
     gateway_ip_addrs_step: 0.0.0.1
     udp_src_port:
     udp_dst_port:
+    mac_addrs_left:
+    mac_addrs_right:
 
     # Traffic Generator Profiles
     # In case you have multiple testbeds or traffic generators,
@@ -167,6 +185,10 @@ traffic_generator:
     # `tool`: Traffic generator tool to be used (currently supported is `TRex`).
     # `ip`: IP address of the traffic generator.
     # `cores`: Specify the number of cores for TRex traffic generator. ONLY applies to trex-local.
+    # `software_mode`: Advice TRex to use software mode which provides the best compability. But
+    #                  note that TRex will not use any hardware acceleration technology under
+    #                  software mode, therefore the performance of TRex will be significantly
+    #                  lower. ONLY applies to trex-local.
     # `interfaces`: Configuration of traffic generator interfaces.
     # `interfaces.port`: The port of the traffic generator to be used (leave as 0 and 1 resp.)
     # `interfaces.switch_port`: Leave empty (reserved for advanced use cases)
@@ -178,6 +200,7 @@ traffic_generator:
           tool: TRex
           ip: 127.0.0.1
           cores: 3
+          software_mode: false
           interfaces:
             - port: 0
               switch_port:
@@ -190,9 +213,6 @@ traffic_generator:
 # -----------------------------------------------------------------------------
 # These variables are not likely to be changed
 
-# The openrc file
-openrc_file:
-
 # Number of seconds to wait for VMs to pass traffic in both directions
 check_traffic_time_sec: 200