# 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
# Number of vCPUs for the flavor
vcpus: 2
# Memory for the flavor in MB
- ram: 8192
+ ram: 4096
# Size of local disk in GB
disk: 0
# metadata are supported and can be added if needed, optional
# `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']
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,
# `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)
tool: TRex
ip: 127.0.0.1
cores: 3
+ software_mode: false
interfaces:
- port: 0
switch_port:
# -----------------------------------------------------------------------------
# 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
segmentation_id:
physical_network:
+# In the scenario of PVVP + SRIOV, there is choice of how the traffic will be
+# handled in the middle network. The default (false) will use vswitch, while
+# SRIOV can be used by toggling below setting.
+use_sriov_middle_net: false
+
# EXT chain only. Names of edge networks which will be used to send traffic via traffic generator.
external_networks:
left: 'nfvbench-net0'
# Defaults to disabled
log_file:
-# When enabled, all logs will be sent to a fluentd server at the requested IP and port
-# The fluentd "tag" and "label" fields for every message will be set to "nfvbench"
+# When enabled, all results and/or logs will be sent to a fluentd servers at the requested IPs and ports
+# A list of one or more fluentd servers identified by their IPs and port numbers should be given.
+# For each recipient it is possible to enable both sending logs and performance
+# results, or enable either logs or performance results. For enabling logs or results logging_tag or
+# result_tag should be set.
+
fluentd:
- # by default (logging_tag is empty) nfvbench log messages are not sent to fluentd
- # to enable logging to fluents, specify a valid fluentd tag name to be used for the
- # log records
- logging_tag:
+ # by default (logging_tag is empty) nfvbench log messages are not sent to fluentd
+ # to enable logging to fluents, specify a valid fluentd tag name to be used for the
+ # log records
+ - logging_tag:
+
+ # by default (result_tag is empty) nfvbench results are not sent to fluentd
+ # to enable sending nfvbench results to fluentd, specify a valid fluentd tag name
+ # to be used for the results records, which is different than logging_tag
+ result_tag:
- # by default (result_tag is empty) nfvbench results are not sent to fluentd
- # to enable sending nfvbench results to fluentd, specify a valid fluentd tag name
- # to be used for the results records, which is different than logging_tag
- result_tag:
+ # IP address of the server, defaults to loopback
+ ip: 127.0.0.1
- # IP address of the server, defaults to loopback
- ip: 127.0.0.1
+ # port # to use, by default, use the default fluentd forward port
+ port: 24224
- # port # to use, by default, use the default fluentd forward port
- port: 24224
+ # by default (logging_tag is empty) nfvbench log messages are not sent to fluentd
+ # to enable logging to fluents, specify a valid fluentd tag name to be used for the
+ # log records
# Module and class name of factory which will be used to provide classes dynamically for other components.
factory_module: 'nfvbench.factory'
# Custom label added for every perf record generated during this run.
# Can be overriden by --user-label
-user_label:
\ No newline at end of file
+user_label:
Code Review / nfvbench.git / blobdiff