summaryrefslogtreecommitdiffstats
path: root/VNFs/DPPD-PROX/tx_pkt.c
AgeCommit message (Collapse)AuthorFilesLines
2020-05-29VLAN support with vdev devices + few other changesXavier Simonart1-8/+12
- 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-51/+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-29Improve performance in l3 submodeXavier Simonart1-1/+2
Two cases where performance has been improved - When using a gateway from a routing table (l3 submode), store the mac within the next hop table, to avoid a hash_lookup. This gives ~10% improvement. - Read tsc only once per bulk (of up to 64 packets). This gives ~10% improvement to swap, 4% to gen. In addition a small fix has been added, preventig "No route" Error to be written too aften. Change-Id: I8a7ab74a32f09c8ff47f751ee91e84afee1b2147 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Added initial support for BGPXavier Simonart1-0/+70
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-29Improve ctrlplane performanceXavier Simonart1-4/+12
The crlplane performance has been improved. This is necessary when handling many IP in L3 mode (i.e. many ARP Requests/Replies). Before this change, arp timer was updated as soon as an arp request was tentativaly sent to the master. This means that, if the request failed to be sent (e.g. ring full) we had to wait arp_update_time (default 1sec) before trying again. Now arp_update_time is only used when an arp reply is received. If a request has been successfully sent, then the arp timer is updated by 1 second (i.e. we will not send any arp reuest for this IP within this second) If we failed to send the request, then the timer is updated by 100 msec which means we will wait 100 msec before trying again. A too high value here would have meant that we have to wait a long time before trying again. A too short value overload the master ring with request to transmit ARP requests, so that master is unable to handle arp replies. arp_update_time is now also partly randomized to avoid all IPs to request arp request at the beginning of the test. So if arp_update_time is 10 sec then the configuration sets it to 5 to 15 sec. As a final note the following parameter (already implemented before) can be changed to improve ctrlplane performance (at the cost of dataplane) ctrl path polling frequency=10000 Change-Id: I9660458a22e7442eaa0c83aaa0c9893a15069f98 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-04-24Fix dump packets commandXavier Simonart1-1/+1
dump packets (e.g. dump 1 0 1) was in some cases dumping more packets than expected. Proper count of packets is now dumped. Change-Id: I0974465d617eda00e77ee87148bf96991ecd3ed7 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-01-03Prevent dropping ARP packetsXavier Simonart1-0/+33
JIRA: SAMPLEVNF-152 When system is overloaded, ARP packets were sometimes dropped, as any other packets. This was causing two issues: - The count of TX non dataplane packets was wrong - If many consecutive ARP packets were dropped, the underlying switch might see its ARP timer expiring, causing performance degradation (packets being broadcasted). ARP packets are now always sent as no-drop. Change-Id: I9a86cbf8c4b56a178f86bc789153f1fa49ddf73f Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-13Add support for zero packet loss in PROX L3 mode.Xavier Simonart1-3/+20
In L3 mode, prox is extracting IP destination address in the packets. It uses this destination address to find the MAC address. If the MAC address is not found, it sends a ARP request. It also sends ARP request when it realizes that some timeout expired. However, PROX was using the mbuf of the existing packets (to be forwarded) to send the ARP. This resulted in packet loss. Now PROX is generating ARP requests using mbuf from an ARP mempool. Some clean up was also done. Change-Id: Icb6083a8cdf88789553ad23c32ca12d6b7ba7f08 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-13Clean up debugging messagesXavier Simonart1-4/+4
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-02-13Fix potential crash in rx and tx distributionXavier Simonart1-1/+4
In some (rare) modes, more than 64 packets can be received through one rx function. This is for instance the case of the lat mode. Change-Id: Ie733c927a8e116c679c464f2551768185ef85366 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2017-10-25Merge changes from PROX-v041Patrice Buriez1-52/+173
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/+665
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>