1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
|
##
## Copyright (c) 2021 Intel Corporation
##
## Licensed under the Apache License, Version 2.0 (the "License");
## you may not use this file except in compliance with the License.
## You may obtain a copy of the License at
##
## http://www.apache.org/licenses/LICENSE-2.0
##
## Unless required by applicable law or agreed to in writing, software
## distributed under the License is distributed on an "AS IS" BASIS,
## WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
## See the License for the specific language governing permissions and
## limitations under the License.
##
# This README is describing the format of all the rapid test files that you can
# find in this directory.
# These files can be specified as a parameter for the runrapid.py script, using
# the --test [testfile] option. The default file name is specified in
# rapid_defaults.py and is basicrapid.test.
#
# There are 3 types of sections in this config file:
# - the [TestParameters] section, which defines how many [TestMx] sections and
# how many [testy] sections need to be present in this file.
# - at least one TestMachine section [TestMx], where x is the index of the Test
# machines starting at index 1
# - at least one tests definition section [testy], where y is the index of the
# test to be run. Index starts at 1.
[TestParameters]
# The name of this test. Can be chosen freely to describe this test
name = BasicSwapTesting
# Defines how may different tests will be executed when running this test file.
# This is usually set to 1. You need to define as many [testy] sections as
# defined in this parameter.
number_of_tests = 1
# The next parameter defines how many PROX instance are needed to run this test.
# You need to define as many [TestMx] sections as defined in this parameter.
total_number_of_test_machines = 2
# Some rapid tests are reporting the latency percentile statistics. This
# parameter defines which latency percentile will be used for this test.
lat_percentile = 99
# When doing ipv6 testing, this parameter needs to be set to True, default is
# False. This is used by the generator code to calculate the proper packet
# header length offsets.
ipv6 = True
# The following section describes the role of the first Test Machine. Note that
# the connection details for each PROX instance are defined in the environment
# file (default: rapid.env). There is a --map parameter for runrapid.py that
# specifies how the Test machines are mapped onto the available PROX instances.
[TestM1]
# Name can be freely chosen
name = Generator
# the PROX configuration files that will be used to start PROX on this Test
# machine. This configuration file will define the role that PROX will play in
# this Test machine.
config_file = configs/gen.cfg
# The values of the remaining parameters in this section are passed on to the
# PROX configuration file through a file called parameters.lua
#
# The next parameter defines the destination Test machine index. This will be
# used by a generator to define which destination MAC or IP addresses should be
# used in the generated packets. The fact that we use MAC or IP addresses is
# defined by the use of l2 or l3.
dest_vm = 2
# The next parameter defines the GW Test machine index. This will be
# used by a generator to define which GW MAC or IP addresses should be
# used in the generated packets. The fact that we use MAC or IP addresses is
# defined by the use of l2 or l3.
#gw_vm = 2
# mcore defines whichmaster core PROX will use. It is not advised to change
# this. The PROX instances are optimized to use core 0 for the master and all
# other cores for DPDK usage.
mcore = [0]
# gencores defines which cores will be used to generate packets. If the
# generator is not able to generate enough packets, you migth want to assign
# more cores to the generator. Make sure not to use more cores in these
# variables than you have available in your PROX instance.
gencores = [1]
# latcores defines that cores that will do the task of measuring latency,
# reordering and other statistics.
latcores = [3]
# Non generator Test machines only require the cores parameter to find out on
# which cores they need to place the PROX tasks.
# cores = [1-3]
# cores = [1,2,3]
# The bucket_size_exp parameter is only needed for generator machines when
# collecting percentile latency statistics. PROX is assigning every packet to
# one of the 128 latency buckets. The size of the latency buckets depends on
# the processor frequency and this parameter using some complicated formula.
# iteration_data['bucket_size'] = float(2 ** BUCKET_SIZE_EXP) /
# (old_div(float(iteration_data['lat_hz']),float(10**6)))
# Teh result is expressing the width of each bucket in micro-seconds.
# The minimum value (which is also the default value) for this parameter is 11.
# For a processor with a frequency of 2Ghz, and a parameter of 11, this results
# in a bucket size of 1.024 us. Since we have 128 buckets, the maximum latency
# that can be stored in the buckets is in theory 128 * 1.024 = 131.072 us. We
# will however place every measurement with a latency higher than 131.072 us in
# the last bucket. When you are dealing with higher latency, you will have to
# increase this parameter. Each time you increase this parameter by 1, you will
# double the bucket size.
#bucket_size_exp = 12
# We can only monitor one generator and one reflector (swap) Test machine.
# Monitoring means that we will sue the statistics coming from these Test
# machines to report statistics and make decisions on the success of a test.
# Test machines not playing a role in this process, need to have the monitor
# parameter set to false. You can only have 1 generator machines and 1 SUT Test
# machine. The parameter can be set to false for background traffic Test
# machines, GW Test machines, etc... Default is true
#monitor = false
# The prox_socket parameter instruct the rapid scripts to connect to the PROX
# instance and collect statistics. Default is true. If set to none, we will not
# collect any statistics from this machine
#prox_socket = false
# The prox_launch_exit parameter instructs the script to actually start PROX at
# the beginning of a test, and to stop it at the end. The default is true. You
# can set this parameter to false in case you want to start PROX manually and
# inspect the PROX UI, while the rapid scripts are dringing the testing.
#prox_launch_exit = false
[TestM2]
name = Swap
config_file = configs/swap.cfg
mcore = [0]
cores = [1]
#prox_socket = false
#prox_launch_exit = false
# The following section describes the first test that will run. You need at
# least 1 test section. In most cases, you will only have one.
[test1]
# The test that we will run. A limited set of tests are available: you need to
# select from the available tests as you can see in the runrapid.py code.
# At the moment of the writing of this text, we have the following tests
# available: flowsizetest, TST009test, fixed_rate, increment_till_fail,
# corestatstest, portstatstest, impairtest, irqtest, warmuptest
test=flowsizetest
# The next warmup parameters, are used to warm up the system before the actual
# test is started. This is to make sure ARP is being resolved in PROX and in the
# underlying infrastructure so that this does not influence the results.
# warmupflowsize instruct how many parallel flows need to be generated during
# warmup
warmupflowsize=512
# Give the imix packet size that will be used during warmup. It is a list of
# packet sizes
warmupimix=[64, 300, 250, 250, 80]
# The speed at whcih we will generate packets during the warmup phase. The speed
# is expressed as a percentage of 10Gb/s. You could say this is expressed in
# units of 100Mb/s.
warmupspeed=1
# warmuptime is the time this warmup phase will run. It is expressed in seconds.
warmuptime=2
# Each element in the imix list will result in a separate test. Each element
# is on its turn a list of packet sizes which will be used during one test
# execution. If you only want to test 1 size, define a list with only one
# element.
imixs=[[64],[64,250,800,800]]
# the number of flows in the list need to be powers of 2, max 2^30
# If not a power of 2, we will use the lowest power of 2 that is larger than
# the requested number of flows. e.g. 9 will result in 16 flows
# Each element in this list will result in an seperate test.
flows=[64,500000]
# The drop_rate_threshold defines the maximum amount of packets that can be
# dropped without decalring the test as failed. This number is expressed as a
# percentage of the total amount of packets being sent by the generator. If this
# number is set to 0, the test will only be declared succesful, if zero packets
# were dropped during this test
drop_rate_threshold = 0.1
# Setting one of the following thresholds to infinity (inf), results in the
# criterion not being evaluated to rate the test as succesful. The latency
# tresholds are expressed in micro-seconds.
lat_avg_threshold = 50
lat_perc_threshold = 80
lat_max_threshold = inf
# When we run binary searches, we are always trying at a new speed, halfway
# between the last failed speed and the last succesful speed (initially, we
# consider 0 as that last succesful speed). When stop doing this binary search
# when the difference between the last speed and the news speed is less than
# what is defined by accuracy, expressed in percentages.
accuracy = 1
# Speed at which we will start the binary search, expressed in percentage of
# 10Gb/s.
startspeed = 50
# When using ramp_step, we will at the beginning of each measurement, increase
# the traffic slowly, till we reach the requested speed. Can be used with
# certain soft switches that are reconfiguring the resource usage, based on the
# actual traffic. In order not the influence the measurement, we then slowly go
# to the requested traffic rate.
#ramp_step = 1
|
