| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Only flows from ranges are supported so far. This means that
flows generated through randoms are not supported yet.
Misordered packets can now be detected per flow.
flow definition is hard-coded as 5 tuple (proto, ip/udp src/dst).
The generator writes flow_id and packet_id within the packets (4 + 5 bytes).
This means that, if all latency, packet_id, signature, accuracy, flow_id and packet_id_in_flow
parameters are set, the minimum packet size is 72 bytes.
This feature is enabled through the following parameters:
On the gen side:
- packet id in flow pos: position (5 bytes) for packet id
- flow id pos: flow id pos (4 bytes)
On the lat side
- flow_count: the number of flows received by the latency core. If not enough
flows are configured, then an error message is displayed (once) and packet_reordering
count is only measured for those flows
- packet id in flow pos: position (5 bytes) for packet id
- flow id pos: flow id pos (4 bytes)
Misordered packets (and extent) are reported per core as before.
No change related to duplicate packets (not measured per flow as a duplicate packet is not per flow...).
Signed-off-by: Xavier Simonart <simonartxavier@gmail.com>
Change-Id: I07517df87dfebec81408baf1decb647d9a0edd94
|
|
Early Loss Detection was supporting a maximum latency of 16k
packets i.e. 1ms at 64 Bytes / 10Gbps.
This has been increased by 64.
Drawback is that early loss detection might take much longer
(1 million packets)
Signed-off-by: Xavier Simonart <simonartxavier@gmail.com>
Change-Id: I3e8dae6a27e72e48757a66e0097d17be924211ad
|
|
Signed-off-by: Xavier Simonart <simonartxavier@gmail.com>
Change-Id: I93bc98069bf60d8b727fd877bf89087c57ad2dd9
|
|
The "Latency" screen has been updated with 3 columns:
- mis-ordered
Count the number of mis-ordered packets.
- extent:
Gives an indication of how mis-ordered the packets are.
Receiving packet "x - 5" after receiving packet "x" will
cause an extent of 5.
- duplicate:
Count number of duplicate packets.
Following commands have been added for the impair mode:
- proba no drop: replaces the former "probability" command.
Percentage of forwarded packets. So 99.5 means 0.5% of packet drop.
- proba delay
Percentage of delayed packets for the impair mode.
- proba duplicate
Percentage of duplicate packets.
Similar parameters are supported within the config files:
- proba no drop
- proba delay
- proba duplicate
Note: it is recommanded to use the signature when measuring packet
misorder, as otherwise unexpected packet would cause miscounts.
Change-Id: I037f606f264d6e2bd7f123df5ed57ab7df8386d7
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
- Latency Distribution (i.e. histograms) has been added when latency is enabled.
- Histograms are now compiled by default.
- A bug has also been fixed, which was causing strange behavior in the histograms
(due to bucket size being overwritten).
- The default bucket size has been changed to "11" which means that the size of each bucket
is now (1 cycle << 11) = 2048 cycles = 1 microsecond at 2GHz. It was (1 << (10 - 1)).
As there are 128 latency buckets, it is not possible to show all of them on the display.
Hence the latency buckets are displayed based on on the assumption that the minimum latency is usually relatively
stable and that the maximum latency change more often.
- The first empty buckets are not shown (i.e. buckets empty for all tasks)
- If more than 15 buckets are non empty, then the buckets are combined, so that a maximum of
15 (bigger) buckets are shown
- If less than 15 buckets are non empty, the following (empty) buckets are shown
(this avoid seeing every x seconds some columns being added and removed).
Change-Id: I27fe6ac0e513a5558e42ff2e74255c55ba79516d
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
This commit prepares PROX for supporting changes from DPDK 19.08
Mainly, the "sed" listed below were run.
In addition,
- some forward definition have been removed,
- prox_compat.h has been updated
- prox_compat.h has been included where necessary.
Hence such a commit is rather easy to review and to reapply
on other branches if necessary.
sed -i 's/struct ether_hdr/prox_rte_ether_hdr/g' *.h
sed -i 's/struct ether_hdr/prox_rte_ether_hdr/g' *.c
sed -i 's/struct ether_addr/prox_rte_ether_addr/g' *.c
sed -i 's/struct ether_addr/prox_rte_ether_addr/g' *.h
sed -i 's/prox_rte_ether_addr_port/struct ether_addr_port/g' *.c
sed -i 's/prox_rte_ether_addr_port/struct ether_addr_port/g' *.h
sed -i 's/struct vlan_hdr/prox_rte_vlan_hdr/g' *.c
sed -i 's/struct vlan_hdr/prox_rte_vlan_hdr/g' *.h
sed -i 's/struct ipv4_hdr/prox_rte_ipv4_hdr/g' *.h
sed -i 's/struct ipv4_hdr/prox_rte_ipv4_hdr/g' *.c
sed -i 's/struct ipv6_hdr/prox_rte_ipv6_hdr/g' *.c
sed -i 's/struct ipv6_hdr/prox_rte_ipv6_hdr/g' *.h
sed -i 's/struct udp_hdr/prox_rte_udp_hdr/g' *.c
sed -i 's/struct udp_hdr/prox_rte_udp_hdr/g' *.h
sed -i 's/struct tcp_hdr/prox_rte_tcp_hdr/g' *.c
sed -i 's/struct tcp_hdr/prox_rte_tcp_hdr/g' *.h
sed -i 's/struct prox_rte_ether_addr_copy/ether_addr_copy/g' *.c
sed -i 's/struct prox_rte_ether_addr_copy/ether_addr_copy/g' *.h
sed -i 's/struct prox_rte_ether_addr_copy/prox_rte_ether_addr_copy/g' *.c
sed -i 's/struct prox_rte_ether_addr_copy/ether_addr_copy/g' *.h
sed -i 's/prox_rte_ether_addr_copy/ether_addr_copy/g' *.h
sed -i 's/prox_rte_ether_addr_copy/ether_addr_copy/g' *.c
sed -i 's/ether_addr_copy/prox_rte_ether_addr_copy/g' *.c
sed -i 's/ether_addr_copy/prox_rte_ether_addr_copy/g' *.h
sed -i 's/prox_rte_ether_hdr_arp/struct ether_hdr_arp/g' *.h
sed -i 's/prox_rte_ether_hdr_arp/struct ether_hdr_arp/g' *.c
sed -i 's/struct vxlan_gpe_hdr/prox_rte_vxlan_gpe_hdr/g' *.h
sed -i 's/struct vxlan_gpe_hdr/prox_rte_vxlan_gpe_hdr/g' *.c
sed -i 's/eth_random_addr/prox_rte_eth_random_addr/g' *.c
sed -i 's/eth_random_addr/prox_rte_eth_random_addr/g' *.h
sed -i 's/ETHER_CRC_LEN/PROX_RTE_ETHER_CRC_LEN/g' *.c
sed -i 's/ETHER_CRC_LEN/PROX_RTE_ETHER_CRC_LEN/g' *.h
sed -i 's/ETHER_HDR_LEN/PROX_RTE_ETHER_HDR_LEN/g' *.c
sed -i 's/ETHER_HDR_LEN/PROX_RTE_ETHER_HDR_LEN/g' *.h
sed -i 's/ETHER_MAX_LEN/PROX_RTE_ETHER_MAX_LEN/g' *.c
sed -i 's/ETHER_MAX_LEN/PROX_RTE_ETHER_MAX_LEN/g' *.h
sed -i 's/ETHER_MIN_LEN/PROX_RTE_ETHER_MIN_LEN/g' *.c
sed -i 's/ETHER_MIN_LEN/PROX_RTE_ETHER_MIN_LEN/g' *.h
sed -i 's/TCP_SYN_FLAG/PROX_RTE_TCP_SYN_FLAG/g' *.c
sed -i 's/TCP_RST_FLAG/PROX_RTE_TCP_RST_FLAG/g' *.c
sed -i 's/TCP_FIN_FLAG/PROX_RTE_TCP_FIN_FLAG/g' *.c
sed -i 's/TCP_ACK_FLAG/PROX_RTE_TCP_ACK_FLAG/g' *.c
Change-Id: I4dfe8be68e618c94dcaae28754579fbeb571bb00
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Accuracy of latency is obtained by writing TX accuracy for packet N
in a later packet i.e. packet N + WINDOW.
If this window is too small, packet N + WINDOW (conveying accuracy
for packet N) might arrive before packet N, resulting in no accuracy
for packet N.
This change increases this window from 64 to 8K packets.
This change should result in a higher number of packets used for
latency measurements when packets are reordered.
This change might have a performance impact as it uses more memory.
Change-Id: I1016fddb66af86605c73a24050238da41cf54152
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
When PROX fails to transmit packets (e.g. because switch or NIC
is overloaded) some cleanup needs to be done related to packet id
and latency.
In addition, in some casesi, the clock estimate is slighly over-estimated
which might result, in rare cases, in negative (hence very high) latencies,
due to the extrapolation of timestamps.
This has been workarounded bydecreasing the extrapolation, tolerating up to 1%
clock estimate error
Change-Id: I1ba17dfe0d5e2f9f9167f4f087ed0d96da1293c2
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Change-Id: Icac622092c35dc197a0f7cb1dcee8afce9f06fa1
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Improve PROX generator performance by pre-calculating bytes_to_tsc.
This improvement is only implemented for non-pcap
generator, where only few different packet sizes are usually generated.
This change might have a negative performance impact in some cases, if
many different packet sizes are generated, resulting in higher memory usage.
This is the case for instance if random is applied to packet size.
In addition, simplified the rx path, receiving now only MAX_PKT_BURST packets
per handle loop.
Before we were trying to empty the NIC looping on RX packets, ending up
with many rx packets per handle loop. This was used to determine an lower bound
for the time the packet was received.
We now set the lower bound when less than MAX_PKT_BURST has been received.
Change-Id: I1ce813d7e4ac1577ea412c590add5d6f94b36ec7
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
JIRA: SAMPLEVNF-151
link speed is used in gen and lat latency extrapolations.
Using a link_speed value lower than the actual link speed
might result in errors (e.g. negative latencies).
Negotiated link speed might be reported slowly (as reported through irq)
Hence it is better to use the device capability link speed.
In addition, this remove the check for link speed changes in fastpath.
Change-Id: I0f475fe5e139b046012de6cd0b710e4390735078
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
RX packets count = TX count + dropped (handled + discarded) count +
non dataplane packets count.
Hence non dataplane packets such as unexpected packets (e.g. dhcp request)
should not b considerded as handled.
Change-Id: I45cef19fed09bb4f86644d56d689a0959a9038db
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
When performing some zero packet loss performance testing on dataplane, it
is important (not) to count non dataplane packets. For instance, one might
receive uexpected packets from a switch, or ARP packets. Or one might need
to transmit ARP packets. Such packets should not be counted as dataplane
packets as for thse packets there is no 1:1 mapping between transmitted
packets and received packets.
To support this, the counters reporting numbers of transmitted and received
packets remain unchanged but two new counters have been added to PROX,
counting respectively number of received and number of transmitted
non-dataplane packets.
On RX side, packets are counsidered as non-dataplane if being ARP or if
they do not countain the proper signature
On TX side, ARP packets are not considered as dataplane packets.
This feature requires configuration of signature.
"dp core stats" command has been added
Change-Id: I98e113cd02f36d540383d343a433592867ad86a9
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Detect, remember and skip bad/unexpected packets:
- too short to hold the latency-related values
- with bad signature
- with invalid generator_id
using a uint64_t-based bitmap.
Also moved variable declarations closer to usage,
added some likely/unlikely hints,
reworked some return statements, and
fixed 32-bit overflow (every ~4s) of rx_time_err computation.
Change-Id: Ib2aadc1af6b7a68601cc080ba66b10d41ff9a64e
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
Change-Id: I937bb38baa51d1902793fa8720a3ea740a583473
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
When link is down at startup, the link_speed returned by DPDK
is 0. This results in un-optimized latency estimates in gen and lat.
With this fix, lat and gen do nothing until link_speed is
properly initialized, and use the right link speed in the fast path.
Change-Id: Id2d14b6966ccfac7cc78db3c5a74e704b42edae7
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Makefile checks for some coding style rules.
Previous commit introduced trailing white-spaces, which broke
compilation.
Change-Id: Ia57fc9b1428b4a9f8537dce4875e62ac55265fe3
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
|
|
Revert back part of commit 9fa316261d7d9
The function abs_diff was erroneously changed to diff_or_zero.
This function was supposed to measure the difference between rx and
tx time; when rx time overflowed and tx time not yet (i.e.
rx time ~= 0 and tx_time ~=UINT32_MAX, this function added UINT32_MAX
to rx_time. The name of the function was confusing and caused the
previous commit. Net effect of previous commit was that every four seconds
the minimum latency was 0
This commit reverse back to the original behavior, with a function name
diff_time.
Change-Id: Ia1b80e48a756cf5df411dcf58ca1cbc835214d13
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Link_speed could be null when prox started with the ports down.
This was potentially causing a crash.
Another task will need to update link speed when the port come
up. Failing to do this results in less accurate latencies
(no extrapolation)
Change-Id: I597b68e30117e6edb9ccb4732c2acedd5eb8ac80
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
- Also changed lat_info.tx_packet_index to uint64_t,
so also did it for task_lat.prev_tx_packet_index and n_loss.
- Adjusted format strings accordingly, and fixed some other formats.
- Adjusted overflow increment to 2^32 (i.e. UINT32_MAX + 1).
- Replaced hard-coded 64 with ACCURACY_BUFFER_SIZE (still hard-coded
in handle_gen.c).
Change-Id: Ia59f36e17c0797a2a958dbe3b2ac420263473524
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
|
|
When doing latency measurements PROX takes into account the
generation or reception of a bulk of packets. For instance, if
PROX receives at time T 4 packets, it knows that the first
packet was received by te NIC before T (the time to receive the other
3 packets, as they were received at maximum link speed).
So the latency data is decreased by the minimum time to receive those
3 packets.
For this PROX was using a default link speed of 10Gbps. This is wrong
for 1Gbps and 40Gbps networks, and was causing for instance issues
on 40 Gbps networks as extrapolating too much, resulting in either
too low latencies or negative numbers (visible as very high latencies).
Change-Id: I4e0f02e8383dd8d168ac50ecae37a05510ad08bc
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
When doing latency measurements the generator can add a
32 bits signature in the packet at a specific location,
so that the receiver only uses the packets generated by the
generator and ignores packets generated for instance by a switch
The is particuly important for latency measurements as we use
data in the packets as timestamps, and packets generated elsewhere
would result in random latency for those packets.
Change-Id: I8352b35aff76ec8d1344a1e492b9dcc20a53f1ce
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
JIRA: SAMPLEVNF-55
PROX is a DPDK-based application implementing Telco use-cases such as
a simplified BRAS/BNG, light-weight AFTR... It also allows configuring
finer grained network functions like QoS, Routing, load-balancing...
(We are moving PROX version v039 to sampleVNF
https://01.org/intel-data-plane-performance-demonstrators/prox-overview)
Change-Id: Ia3cb02cf0e49ac5596e922c197ff7e010293d033
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
|
Xavier Simonart
Xavier Simonart
Patrice Buriez
Deepak S