path: root/VNFs/DPPD-PROX/task_init.c
AgeCommit message (Collapse)AuthorFilesLines
2019-03-06PROX generator: performance optimization (2/4)Xavier Simonart1-4/+0
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 <>
2019-01-03Prevent dropping ARP packetsXavier Simonart1-11/+8
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 <>
2017-12-18Add l3 support for tasks without physical tx portsXavier Simonart1-2/+2
This adds support for tasks in l3 submode receiving from ports but transmitting to rings. ARP related information is exchanged between tasks through master core. Tasks transmitting to physical ports are responsible to transmit arp related packets. Tasks not transmitting to physical ports (and using rings) should not try to transmit arp packets. Transmitting arp packets through ring would be more complex, as we would need extra information (within the mbuf) to distinguish for instance an arp reply comoing from the network and an arp reply coming from a core (as a reply to an arp request). Change-Id: Ib55dc8c39d5e55703a933faa16bcc008f1274929 Signed-off-by: Xavier Simonart <>
2017-11-15Add support for nop mode with l3 submodeXavier Simonart1-6/+6
The l3 submode was not supported in nop mode, as the nop mode uses some specific nop thread (and not generic). When L3 is specified, the nop mode must use the generic thread. In addition the l3 submode is implemented differently than other submodes. It is not supported through task_init structures (i.e. each task does not have to explicitely tell that it supports l3 submode). But this prevented to run both a nop with no submode and a nop with a l3 submode. Note that nop with l3 is usually not very useful - it handles arp (requests and response) but as nop, it does not swap IP addresses. So with a real switch, the packets transmitted will be received back... and l3 mode is usually mainly usefull when using a switch. However, there is at least one nop mode where l3 submode makes sense: when the nop does not transmit. In such cases, for instace used in conjunction with a gen l3, the nop receives all packets and forward the arp requests and responses to the master for handling. Change-Id: I992121db285ba25a11cbb494092a6afc6fe55a58 Signed-off-by: Xavier Simonart <>
2017-10-25Merge changes from PROX-v041Patrice Buriez1-6/+40
Change-Id: Ie6d4e7ce22c27967117a446626f5923643397812 Signed-off-by: Patrice Buriez <>
2017-07-14Adding PROX(Packet pROcessing eXecution engine) VNF to sampleVNFDeepak S1-0/+401
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 Change-Id: Ia3cb02cf0e49ac5596e922c197ff7e010293d033 Signed-off-by: Deepak S <>