summaryrefslogtreecommitdiffstats
path: root/VNFs/DPPD-PROX/handle_lat.c
AgeCommit message (Collapse)AuthorFilesLines
2018-12-20Do not add count of non dataplane packets to dropped countXavier Simonart1-1/+6
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>
2018-10-28Add support for counting non dataplane related packetsXavier Simonart1-3/+8
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>
2018-07-07Fix potential crash with latency accuracyPatrice Buriez1-45/+73
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>
2018-04-23Fix memory leak introduced by 4a65cd84Xavier Simonart1-1/+4
Change-Id: I937bb38baa51d1902793fa8720a3ea740a583473 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-04-17Fix link speed when link is down at startup.Xavier Simonart1-4/+20
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>
2018-03-23Trivial: fix trailing white-spacesPatrice Buriez1-2/+2
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>
2018-03-16Merge "Fix potential crash if link speed is null"Deepak S1-1/+1
2018-03-05Fix minimum latencyXavier Simonart1-5/+11
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>
2018-02-27Fix potential crash if link speed is nullXavier Simonart1-1/+1
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>
2018-02-15Fix latency accuracy and dumping latencies to fileXavier Simonart1-91/+182
- 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>
2018-01-24Fix extrapolation used in latency measurementsXavier Simonart1-4/+28
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>
2018-01-08Fix using signature in latency measurementsXavier Simonart1-0/+3
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>
2017-07-14Adding PROX(Packet pROcessing eXecution engine) VNF to sampleVNFDeepak S1-0/+650
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>