Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
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>
|
|
Different checks were done when setting the generator pkt_size.
In case of wrong pkt_size (e.g. too big) an error was printed but
the pkt_size was still set causing a potential corruption.
In addition, in case of a packet size incompatible with some
of the packet fields (e.g. latency data) PROX was panicing
while this should not happen runtime for such an error.
Change-Id: Ifa11475bf295aaac7b0255c1bf9b5feed8ef90c4
Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
|
|
Change-Id: Ie6d4e7ce22c27967117a446626f5923643397812
Signed-off-by: Patrice Buriez <patrice.buriez@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>
|