summaryrefslogtreecommitdiffstats
path: root/VNFs/DPPD-PROX/handle_gen.c
AgeCommit message (Collapse)AuthorFilesLines
2018-12-14Fix handing configuration error (missing tx port or ring in gen mode)Xavier Simonart1-1/+2
Gen mode requires a tx ring or a tx port. A configuration without those should gracefully report an error. This was causing a crash. Change-Id: Ia30d4d4c87a694da1dfed86587f90b9199c493ab Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-10-31Support for DPDK 18.05 and DPDK 18.08Xavier Simonart1-1/+1
Improve DPDK 18.05 support introduced by 3e532aca. Support for DPDK 18.08. Change-Id: Ide712ee94254b506a0ad88c95a7e01b789f99d48 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-05-25Increase default mbuf size and code simplification/cleanupXavier Simonart1-4/+9
mbuf size was setup to achieve the best performance i.e. using the smallest mbuf and not segmenting packets. However this resulted in complex code, much dependent of the way the pmd are working e.g. a change(fix) in recent dpdk i40e implementation caused a 1782 (=1518+8+256) bytes mbuf to be too small to hold a 1518 bytes packets. Hence this change simplifies the mbuf size selection at the price of a potential decreases in performance - as more memory is now used. Except if jumbo frames are used, the mbuf size will now be the same for all modes. The packets will not be segmented except if jumbo frames are enabled. If jumbo frames are enabled, packets are by default segmented, except if the mbuf size is configured big enough in the config file. Change-Id: I222fcac7a65c0d221d5d422f419deb9c0f864172 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com> Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2018-04-26Add support for generation of jumbo framesXavier Simonart1-21/+59
Change-Id: I63af4e5c5c01a4412d517e33fc7111481fd0524a 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-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-1/+6
- 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-3/+16
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>
2017-12-06Fix checks done when changing generator pkt_sizeXavier Simonart1-10/+25
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>
2017-10-25Merge changes from PROX-v041Patrice Buriez1-302/+99
Change-Id: Ie6d4e7ce22c27967117a446626f5923643397812 Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
2017-07-14Adding PROX(Packet pROcessing eXecution engine) VNF to sampleVNFDeepak S1-0/+1481
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>