| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
Patrice Buriez
Deepak S