VNFs/DPPD-PROX/helper-scripts/rapid/tests/README

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