Module generate traffic using FastClick with throughput and latency measurement
This module supports generating UDP traffic or playing a PCAP.
Both can generate at a given rate (UDP) or acceleration factor (PCAP).
Both can also use a "replay" mode, that is pre:doc:`load <modules/load>`ing packet in memory then replaying them in loop.
Packets are directed towards one NIC of the "server" role using one NIC of the CLIENT and expect to receive packets back on any (eventually the same) NIC.
There is no L3 support (ARP). MAC adresses must be set correctly.
# Usage
Add in your NPF test script (omit the prefixed "//" that prevent loop import here)
//%import@client fastclick-play-single-mt
## Playing a trace
Be sure to pass the variable trace=path/to/trace
The variable LIMIT_TIME will limit the replay time.
## Playing UDP traffic
Give the tag "udpgen" with --tags udpgen to npf cmdline
The variable GEN_LENGTH=128 allows to set the packet size to 128 bytes. Check the variables section below for other parameters.
The variable LIMIT_TIME will limit the replay time.
## Pre:doc:`load <modules/load>`ing in memory
Give the "replay" tag with --tags replay to npf cmdline
The variable :doc:`PKTGEN <modules/PKTGEN>`_REPLAY_COUNT=10 will replay 10 times.
The variable LIMIT_TIME will limit the replay time instead.
## Packet or bit rate (UDP or trace)
Pass the "rate" tag to express a rate in BPS, "prate" for a rate in PPS
Then set GEN_RATE to define the rate
## Timing acceleration (traces, replayed or not)
Use TIMING=0 to play as fast possible the packets (you might consider pre:doc:`load <modules/load>`ing in memory, see below).
Use TIMING=1 to play packets using the original timing, eventually tweaked at X% of the original timing using TIMING_FNT.
For instance TIMING_FNT=200 will replay twice faster. TIMING_FNT can be a function of time (given as x). For instance to start replay at 1% at t=0 then 100% at t=10 and then stay at 100%:
TIMING_FNT=1+min(99,x*10)
Arrange the function so the timing is never 0%. At 0% the system will be unscheduled, as the timing is computed for inter-packet time. At 0%, the next packet is never sent so the time stops.
## Replaying from compressed dump (particular cases)
Set GEN_DUMP=1 to use a FromIPSummaryDump instead of FromDump, the trace parameter should therefore follow the FromIPSummaryDump format. Similarly, use GEN_DUMP=2 to use FromMinDump.
# Zero-loss throughput
Altough not tied to this specific module, it is often combined with experimental design to find the zero-loss-throughput. The following cmdline arguments will give the maximum rate a DUT can forward.
--variables GEN_RATE=[1000000-16000000#1000000]
--exp-design zlt(GEN_RATE,PPS,1.01)
# Multi-threading
Pass the variables GEN_THREADS=X and GEN_RX_THREADS=y to use x threads for TX and y threads for RX. Default is 4 for both.
## Multi-threading with traces
The normal way to use multi-threading would be to round-robin the trace between the threads.
By default, each thread will re-read the same trace, which is generally not convenient.
A more efficient way is to use multiple traces pre-split, for instance one trace per thread.
Use the "GEN_MULTI_TRACE=N" tag to use multiple traces, using -1, -2, ... -N suffixes to the trace. If you only have 4 threads (GEN_THREADS=4), then only traces from 1 to 4 will be used. Inversely, if you have 4 threads but only two traces, the threads 3 and 4 will fail.
If the tag scale_multi_trace tag is given, then the number of traces is fixed always sending traces from 1 to .. GEN_MULTI_TRACE. If GEN_MULTI_TRACE is smaller than GEN_THREADS, some threads will be unused. If GEN_MULTI_TRACE is bigger than the number of threads, then they will be distributed in a round-robin fashion. For instance with 16 traces and 4 threads, the first thread will send trace 1,5,9 and 13. This tags therefore ensure there is no mismatch between the numbers of traces and thread.
## Deactivate latency to improve performance
Use the "gen_nolat" tag to disable latency tracking. This cannot be done using variables.
## Deactivate packet receiption
Use the gen_norx tag to disable receiving packets. This will leave CPU resources available for sending.
## Notes on pipeline
The script has a pipelined mode (use gen_pipeline tag which will set GEN_PIPELINE to 1) used to ensure only one thread reads from the generator (packet trace, UDP, mindump, etc...). The best option is to pre-split a trace, or use UDP generation that can natively be multi-threaded. Use this as last resort or if you got enough performance wihout the hassle of splitting the trace.