summaryrefslogtreecommitdiffstats
path: root/VNFs/DPPD-PROX/handle_master.c
AgeCommit message (Collapse)AuthorFilesLines
2023-01-09Fix socket_id in rte_hash_parametersLuc Provoost1-0/+1
The socket_id was either not initialized or set to 0. This fix sets the proper socket_id to the relevant NUMA node. When running on NUMA nodes other than 0, memory allocation for the hash table could fail. With this fix, it is supposed to work on all NUMA nodes. Signed-off-by: Luc Provoost <luc.provoost@gmail.com> Change-Id: I59887fe064a7e7c96ce2f6ce1c70791844b165b2
2022-12-28Fix tons of deprecation warningsXavier Simonart1-4/+4
reported since DPDK 20.11, 21.05, 21.11 and 22.03, and turned into undeclared symbol errors with DPDK 22.11. Signed-off-by: Xavier Simonart <simonartxavier@gmail.com> Signed-off-by: Patrice Buriez <patrice.buriez@chenapan.org> Change-Id: Ice9a0f662ee057211984f799010701cd81e5a4d0
2022-12-01Fix linker errors with recent GNU ldPatrice Buriez1-0/+2
observed with: - GNU ld 2.35 (gcc 11.3.1) on CentOS Stream release 9 - GNU ld 2.38 (gcc 11.3.0) on Ubuntu 22.04.1 LTS - GNU ld 2.39 (gcc 12.2.0) on Ubuntu 22.10 Signed-off-by: Patrice Buriez <patrice.buriez@chenapan.org> Change-Id: Ie7d7a4f6c4c5f82e68d2ca4e32f96972933d190f
2022-02-11Fix issues when handling unkown ipv6 packetsLuc Provoost1-12/+15
In order to fix this, a new parameter has been introduced: "ipv6 mask length". This can be specified in the port section of the config file. The default value is 8 (bytes). Signed-off-by: Luc Provoost <luc.provoost@gmail.com> Change-Id: I88b0b3906cc247ae5653ad59b8aa425f0cddf347
2021-03-25Do not request IPV6 routing infoLuc Provoost1-5/+5
PROX is not yet dealing with IPV6 routing info (only IPV4). Hence we got a segmentation fault when receiving such information. In a previous commit, we are checking for IPV4 routing info and we do not continue processing of any other routing information. With this fix, we ask the Linux OS NOT to provide IPV6 routing info. The checks when receiving routing information have changed so that we only treat IPV4 and nothing else. Change-Id: I428a036c31014377c8de08da17e51740be0e1de5 Signed-off-by: Luc Provoost <luc.provoost@intel.com>
2021-03-22Ignoring IPV6 routing messagesLuc Provoost1-0/+4
The code was only written to deal with IPV4 routing messages. If we receive an IPV6 routing message, we are now ignoring that message. Change-Id: I0f8044a0331235639bf5cab9abb9c8ce55c3522d Signed-off-by: Luc Provoost <luc.provoost@intel.com>
2021-02-25Fix mbuf corruption when handling icmp messages.Xavier Simonart1-1/+1
Signed-off-by: Xavier Simonart <simonartxavier@gmail.com> Change-Id: I3eeacb550d1ef51a13802d06f06973437afe7d9b
2020-10-16Report failure when tap port is not mapped to real dpdk port.Xavier Simonart1-1/+1
When using "vdev=" in port section, a tap device and an additional dpdk port are created. In most cases, we still want to use a real DPDK device (i.e. bound to an interface such as virtio or a PF or a VF). PROX will now report by default an error when the used [port] is not a DPDK bound device. An additional parameter "virtual=yes" can be added in the port section in case one want to disable this error checking (e.g. specify additional parameter for the vdev device). This patch also fixes a potential endianess issue when configuring IP addresses. Change-Id: Iffdd9552308be3b77cfe2067630647acac2c01fe Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-09-21Added support for multiple vlans in ipv4 vdev modeXavier Simonart1-15/+34
When the following conditions are met: - ipv4 - vdev enabled Then multiple vlans are supported. Multiple vlans can be configured using the vlan_tag option within the port section of the config file. Multiple (different) local_ipv4/prefix must then also be configured within the same section. Note that for ipv6 multiple vlans are not supported (yet) Also, when vdev is not enabled, multiple vlans are also not (yet) supported. Change-Id: I38b6cd98ff2a0f484d1bf0910b15413ba21ae6d6 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-09-21Added support for VLAN in IPv6Xavier Simonart1-25/+18
Change-Id: Ib1b3d54f9cb8e4284eee7ed0998e96370762a17e Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-09-21Added support for reporting packet (mis)order.Xavier Simonart1-1/+1
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-0/+1
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-29VLAN support with vdev devices + few other changesXavier Simonart1-32/+47
- vdev devices now support VLAN. - kernel tap device can be configured with a netmask (/24 was always used in previous version). - when sending a (fake) packet to the kernel, this packet will now not be routed by the kernel (i.e. it will leave through the interface configured by PROX). This might change in the futture when PROX supports multiple VLANs per port. But today it prevents ARP being sent on management interfaces. - Log error in case kernel unable to send packet. - Added support for comments (';') in lua sections. - Prevent duplication of local_ipv4 - should now be configured in port section local_ipv4 in core section still supported Change-Id: I8f9a40fe6ad6f3013ff91b58b44627c7f34081e6 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Added initial support for NDP (IPv6)Xavier Simonart1-105/+485
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-29Fix mbuf leak and stop sending pseudo packetXavier Simonart1-2/+2
In addition to a mmbuf leak when receiving netlink routes packets this commit prevents sending the PROX pseudo packet i.e. the packet PROX sends to the kernel socket to have it generate an ARP request. Change-Id: Iabbdecbe412e4b90ac0df7e30fa36d096c5326f0 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Added initial support for BGPXavier Simonart1-81/+189
Through this commit BGP messages are forwarded to tap device Netlink messages are enabled to receive route Updates. In addition, generating tasks can also specify a routing table which will be used when sending packets The routes initialized by the routing table can be changed through the reception of BGP messages Change-Id: I187ba9a921885cbc9b209aae5fb654309e3388b8 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Fix ctrlplane handling vdevXavier Simonart1-21/+20
Change-Id: I8f570940d2c4e1fc09ebae03105e436f5caebbd3 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Added support for netlinkXavier Simonart1-56/+297
Through this commit ARP and ICMP messages are forwarded to the kernel when vdev tap devices are enabled, as well as PROX l3 mode. ICMP support has also been added to master (i.e. PROX L3 mode) and to swap (so when L3 submode is not enabled). Change-Id: Ie6bf52cbae7171bfca041ff18651d4ec866f44cd Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Add support for vdev tap devicesXavier Simonart1-4/+72
This commit adds support for the creation of tap devices. To create a tap device, and associate it with a DPDK port, add within the port section: vdev=<tap_name> local ipv4=<ip_assigned_to_port> <tap_name> will appear as a kernel network device, with an IP <ip_assigned_to_port> ARP packets received from the network on the DPDK interface will be forwarded to the kernel. 1st packet which needs to be generated to a new IP will cause an IP packet to be sent to the kernel (using socket sendto) forcing the kernel to send an ARP_REQUEST. In this commit, there is no notification from the kernel about ARP table changes. This is subject to further commits. Two config files, gen_tap.cfg and swap_tap.cfg have been created. They work one against each other. *** Note however that they do not work if running within the same host (with the port being connected back to back) *** This is due to the fact that the kernel would bypass the ports and use local interface... Change-Id: Iadeec0d99e3c693472ea44bdb9163a3bf97df2fa Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-01-29Prepare for DPDK 19.08 supportXavier Simonart1-4/+4
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-01-30Fix memory leak in L3 submodeXavier Simonart1-0/+2
In L3 submodes, there were two memory leaks - when a L3 core was restarted, causing around 2MB leak and a potential issue after 256 start/stop - a potential mbuf leak when handling arp replies Those have been fixed Change-Id: I348478fa5967936297850432e93667e12b0adac4 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-13Fix issue in l3 mode when no arp reply was receivedXavier Simonart1-7/+26
When no arp reply was received in l3 mode, the requesting core continuously sends ARP requests every seconds (which is correct). But master core was keeping a list of all requests, while all those requests are the same, resulting in potential table overflow. Change-Id: I13aa1ec4ea88404a690a25678fb6ec72df19a9b9 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-13Clean up debugging messagesXavier Simonart1-6/+5
Print IP address in a.b.c.d format instead of one 32-bit number. Better align debugging information in log file Change-Id: Icfab30836ba83d53f700fcfbdfbd7cf238ed7bf8 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-01-04Add support for DPDK 17.11Xavier Simonart1-1/+1
Change-Id: I5611ead4b61b23d6c1c983852e8c75619e08ecf9 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2017-12-18Add support for multiple tasks generating to same ip in l3 mode.Xavier Simonart1-6/+23
When multiple tasks generate to the same ip in l3 mode (i.e. with arp support), all those tasks generate arp requests. we need to make sure that they all receive a arp-reply i.e. that the master broadcast the reply to all those cores. Change-Id: I7e89196497a1016a94dde167f212b1f6ed03bcfe Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2017-10-25Merge changes from PROX-v041Patrice Buriez1-0/+348
Change-Id: Ie6d4e7ce22c27967117a446626f5923643397812 Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>