summaryrefslogtreecommitdiffstats
path: root/VNFs/DPPD-PROX/handle_gen.c
AgeCommit message (Collapse)AuthorFilesLines
2022-02-06Added scripting support for rangesXavier Simonart1-1/+16
Signed-off-by: Xavier Simonart <simonartxavier@gmail.com> Change-Id: I532fd630498c2b00a91209ff7c3611fd09b460eb
2022-01-03Add support for detection of misordered packets per flowXavier Simonart1-18/+198
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
2021-12-20store packet id in gen and swapXavier Simonart1-1/+60
Support configuration option for specifying number of packets which we will store (gen and swap). Packets are stored runtime in a buffer and written to disk at exit. Signed-off-by: Xavier Simonart <simonartxavier@gmail.com> Change-Id: Iab1c9c13048b6919f77392953675cb8c48aad8e4
2021-09-11Basic support for ranges in generatorXavier Simonart1-0/+47
This commit add initial support for ranges. Ranges can now be specified using an offset and a range, in a similar way as random. e.g.: range=2-16001 range_offset=28 The two previous lines will range the src IP address from x.x.0.2 to x.x.3e.81 in an IPv4 packet. The range option will write as many bytes as the bytes needed for the max (2 bytes in the example above), up to 4 bytes. Runtime, the generator will iterate through the range in a linear way, starting from the min. No check are done whether range overlap themselves or whether they overlap with randoms. As of now, no support for command line or script option. Signed-off-by: Xavier Simonart <simonartxavier@gmail.com> Change-Id: I98a1757998955f48631a5929bd7534481975eedc
2020-11-05Fix setting imx pkt sizes through config filesXavier Simonart1-1/+9
Change-Id: I0e5098747cc496da8632e8d6f779e418da03dc4a Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-09-21Added support for reporting packet (mis)order.Xavier Simonart1-6/+6
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>
2020-05-29Fix compilation issues on old DPDKXavier Simonart1-1/+8
Also fixed minor issues such as - prevent using vdev on DPDK <= 17.05 as not supported - potential segmentation fault after panic (if panic thrown early in prox initialization) Change-Id: I49a1962e95a4a44dddadd1fdd906e1b3b232465c Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Add support for latency measurement for IMIX packetsXavier Simonart1-6/+26
Before this patch latency measurements were only supported if signature was disabled. Change-Id: I565b00f76818ab42e9cca4ddc32f9d857648929d Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Fix source mac address when applying imixXavier Simonart1-0/+3
Change-Id: I8cbbe1b08af9b5472c304f2fba3635f0a084fdd8 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Added initial support for NDP (IPv6)Xavier Simonart1-32/+126
Following messages are now handled by PROX - router_solicitation - neighbour_solicitation - router_advertisement - neighbour_advertisement The following parameters are supported (through the PROX config file) - sub mode=ndp This will enable handling of router and neighbour solicitation and advertisement. - local ipv6=xxxx:xxxx:xxxxx:xxxx:xxxx:xxxx:xxxx:xxxx This will configure the local IPv6 address of the port. This parameter is optional. If not specified, the local IPv6 will be calculated from the EUI. - global ipv6=xxxx:xxxx:xxxxx:xxxx:xxxx:xxxx:xxxx:xxxx This will configure the global IPv6 address of the port. This parameter is optional. If not specified, the global IPv6 will be calculated from the EUI and the router prefix received from the router. - ipv6 router=yes This will cause the core to behave as an IPv6 router i.e. it will generate Router Advertisement messages This is only useful in back to back cases, when no real IPv6 router is present in the setup. - router prefix=xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx The router prefix usedin the router advertisement The prefix will be used by the node to build an IPv6 global address in cases none were configured. "Unsollicited NA" parameter has been added within the core/task section. If set to yes (Unsollicited NA=yes), then an unsollicited neighbour Advertisement is sent at startup A same core/task cannot support both l3 and ndp mode. Those messages will be generated or handled when submode is set to "ndp": - neighbour sollicitation - neighbour advertisement - router sollicitation - router advertisement An example configuration is provided: config/ipv6.cfg in which port 0 / core 1 plays the role of the generator and port 1 / core 2 plays the role of the swap. Change-Id: Id0ab32d384448b4cf767fb4a1c486fc023f4f395 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Added support for IMIX through config and command lineXavier Simonart1-121/+274
In Prox configuration IMIX can be specified using the following syntax: imix=pkt_size,pkt_size... Up to 127 different pkt sizes can be specified. Through command line, the following syntax can be used imix core_id task_id pkt_size,pkt_size... Up to 127 packet sizes can be specified. When IMIX is enabled, PROX will loop through the list of packet sizes. PROX supports two different submodes to handle pcap files. In the 1st submode (default, no submode specified), timestamps from the pcap file are ignored. In this submode IMIX is supported as well and each packets in the pcap file will be generated with all IMIX sizes. In the second submode, called pcap in gen mode, packets are generated at the timestamp specified in the pcap file. This submode does not support IMIX. Change-Id: I53cbf1378a5364254285b81e6848350d98561184 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-01-29Added support for DPDK 19.08Xavier Simonart1-2/+2
Change-Id: I090bf8f1cd5a5d2dfa4f336bc66c46cc03d6c5bb Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-01-29Prepare for DPDK 19.08 supportXavier Simonart1-31/+31
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>
2019-10-11Fix generation through pcap fileXavier Simonart1-20/+20
- When using "pcap file" argument in PROX config file in the gen mode (and no submode), packets were truncated to 8 bytes (and a warning printed) This has been fixed. - "Set value" command was checking whether offset was within first 1518 bytes unrespective to the mtu (e.g. jumbo packets). This has been fixed. - There was a limit of 64K packets loaded from a pcap file (which could be overwritten through PROX config). This limit has been removed - by default all packets from pcap are loaded - When pcap was loaded, memory was allocated to store the packet. However just enough memory was allocated, so that there was no way to change (increase) packet size through command line after that. Now memory is allocated to store up to mtu size - While "set value" command was acting on all packets, "pkt size" command was only changing the first packet. This has now been changed and both commands change all the packets. - A few other minor cleanups. Change-Id: I7264cee8d57e3e6a405dfd7e7a52a95b99399d99 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-08-05Fix reset valueXavier Simonart1-4/+11
In addition to resetting all values set by the user, reset value was also resetting internal configuration. It resulted that the src mac address in the outgoing packet was set to whatever was specified in pkt inline, which is wrong (by default src mac address should be set the the port mac address). Note that reset value reset any "set values" but does not reset the packet size. Change-Id: I9d1cd92be9f5814bd7b104932dd6ffe5df3b6edd Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-06-14Increase window size for latency accuracyXavier Simonart1-5/+5
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>
2019-03-08Fix PROX generator latencyXavier Simonart1-2/+18
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>
2019-03-06PROX generator: performance optimization (3/4)Xavier Simonart1-13/+4
The Signature is now written in the pkt template instead of being written in each packet Change-Id: I58ca99ff47260b82ce9471b7a47a11edbd14c582 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-03-06PROX generator: performance optimization (2/4)Xavier Simonart1-47/+41
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>
2019-03-06PROX generator: performance optimization (1/4)Xavier Simonart1-18/+9
Improve PROX generator performance by - Cleanup some old code checking for unset flags Change-Id: Icd7ff0a8d17f11f1a1bd09bef4fb40574257c093 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-02-20Use link speed from device capability instead of negotiated speedaXavier Simonart1-0/+13
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>
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>