From: Ido Barnea Date: Thu, 19 May 2016 09:49:03 +0000 (+0300) Subject: per flow latency tutorial - not final version X-Git-Url: https://gerrit.fd.io/r/gitweb?a=commitdiff_plain;h=5419e375097c9d66eb7691866886b6580e471538;p=trex.git per flow latency tutorial - not final version --- diff --git a/trex_stateless.asciidoc b/trex_stateless.asciidoc index 225f60e1..f5b02619 100755 --- a/trex_stateless.asciidoc +++ b/trex_stateless.asciidoc @@ -510,7 +510,7 @@ In this example all the packets will be routed to `TenGigabitEthernet0/1/0` port ==== Tutorial: Connect from a remote server -*Goal*:: Connect by console from remote machine to a TRex server +*Goal*:: Connect by console from remote machine to a TRex server *Check that TRex server is operational*:: @@ -2940,7 +2940,7 @@ trex> * Per stream statistics are implemented using hardware assist when possible (examples: Intel X710/XL710 NIC flow director rules). * With other NICs (examples: Intel I350, 82599), per stream statistics are implemented in software. * Implementation: -** User chooses 32-bit packet group ID (pg_id) for each stream that need statistic reporting. Same pg_id can be used for more than one stream. In this case, statistics for all streams with the same pg_id will be combined. +** User chooses 32-bit packet group ID (pg_id) for each stream that need statistic reporting. Same pg_id can be used for more than one stream. In this case, statistics for all streams with the same pg_id will be combined. ** The IPv4 identification field of the stream is changed to a value within a reserved range (0xff00 to 0xffff). Note that if a stream for which no statistics are needed has an IPv4 Identification in the reserved range, it is changed (the left bit becomes 0). ** Software implementation: Hardware rules are used to direct packets from relevant streams to rx thread, where they are counted. ** Hardware implementation: Hardware rules are inserted to count packets from relevant streams. @@ -2954,7 +2954,6 @@ trex> * Maximum number of concurrent streams (with different pg_id) on which statistics may be collected: 127 Two examples follow, one using the console and the other using the Python API. -// immediately below is the console example; where's the Python API example? *Console*:: @@ -3097,13 +3096,102 @@ The following shows a flow_stats object for 3 PG IDs after a specific run: ---- -==== Tutorial: Per stream latency/jitter +==== Tutorial: Per stream latency/jitter/packet errors -// [TODO] +* Per stream latency/jitter is implemented by software. This is an extension of the per stream statistics. Meaning, whenever you choose to get latency info for a stream, the statistics described +in the "Per stream statistics" section is also available. +* Implementation: +** User chooses 32-bit packet group ID (pg_id) for each stream that need latency reporting. pg_id should be unique per stream. +** The IPv4 identification field of the stream is changed to some defined constant value (in the reserved range described in the "per stream statistics" section), in order to signal the hardware to pass the stream to software. +** Last 16 bytes of the packet payload is used to pass needed information. Information contains ID of the stream, packet sequence number (per stream), timestamp of packet transmission. -*(Future Feature - not yet implemented)* +* Gathered info (per stream) is sent using a link:http://zguide.zeromq.org/[ZMQ] async channel to clients. + +*Limitations*:: + +* The feature supports 2 packet types: +** IPv4 over Ethernet +** IPv4 with one VLAN tag +* Packets must contain at least 16 bytes payload. +* Each stream must have unique pg_id number. This also means that a given "latency collecting" stream can't be transmitted from two interfaces in parallel (internally it means that there are two streams). +* Maximum number of concurrent streams (with different pg_id) on which latency info may be collected: 128 (This is in addition to the streams which collect per stream statistics). + +Two examples follow, one using the console and the other using the Python API. + +*Console*:: + +The following simple traffic profile defines 2 streams and configures them with 2 different PG IDs. + +*File*:: link:{github_stl_path}/flow_stats_latency.py[stl/flow_stats_latency.py] + +[source,python] +---- + +class STLS1(object): + + def get_streams (self, direction = 0): + return [STLStream(packet = STLPktBuilder(pkt ="stl/yaml/udp_64B_no_crc.pcap"), + mode = STLTXCont(pps = 1000), + flow_stats = STLFlowLatencyStats(pg_id = 7)), <1> + + STLStream(packet = STLPktBuilder(pkt ="stl/yaml/udp_594B_no_crc.pcap"), + mode = STLTXCont(pps = 5000), + flow_stats = STLFlowLatencyStats(pg_id = 12)) <2> + ] + + +---- +<1> Assigned to PG ID 7 +<2> Assigned to PG ID 12 + +The following command injects this to the console and uses the textual user interface (TUI) to display the TRex activity: + +[source,bash] +---- +trex>start -f stl/flow_stats.py --port 0 + +Removing all streams from port(s) [0]: [SUCCESS] + + +Attaching 2 streams to port(s) [0]: [SUCCESS] + + +Starting traffic on port(s) [0]: [SUCCESS] + +155.81 [ms] + +trex>tui -// note TODO +Latency Statistics (usec) + + PG ID | 12 | 13 + ---------------------------------------------- + Max latency | 0 | 0 #<1> + Avg latency | 5 | 5 #<2> + -- Window -- | | + Last (max) | 3 | 4 #<3> + Last-1 | 3 | 3 + Last-2 | 4 | 4 + Last-3 | 4 | 3 + Last-4 | 4 | 4 + Last-5 | 3 | 4 + Last-6 | 4 | 3 + Last-7 | 4 | 3 + Last-8 | 4 | 4 + Last-9 | 4 | 3 + --- | | + Jitter | 0 | 0 #<4> + ---- | | + Errors | 0 | 0 #<5> + +---- +<1> Maximum latency measured over the stream lifetime (in usec). +<2> Average latency over the stream lifetime (usec). +<3> Maximum latency measured between last two data reads from server (We currently read every 0.5 second). + Numbers below are maximum latency for previous measuring periods, so we get latency history for last few seconds. +<4> Jitter of latency measurements. +<5> Indication of number of errors (packet lost/out of order/duplicates) that occured). In the future it will be possible to 'zoom in', to see specific counters. + For now, if you need to see specific counters, you can use the Python API. ==== Tutorial: HLT traffic profile