summaryrefslogtreecommitdiffstats
path: root/VNFs/DPPD-PROX/prox_port_cfg.c
AgeCommit message (Collapse)AuthorFilesLines
2020-05-29Fix compilation issues on old DPDKXavier Simonart1-2/+17
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-6/+22
- 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-29Fix potential core dump when closing ports at exitXavier Simonart1-0/+11
Change-Id: I45ea9741be1c552d8f13a7de027994c23995df69 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Added initial support for NDP (IPv6)Xavier Simonart1-1/+1
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 secondary process & virtual devicesXavier Simonart1-5/+34
A virtual device can be created adding the following option on the eal field within the eal options section: --vdev=net_ring0 This will cause a new (virtual) dpdk port to be created. Such a device can then be used in a primary process as other DPDK devices i.e. a [port x] section must be defined in the configuration file For a secondary process, there is no need to add --vdev, but, of course --proc-type=secondary (or --proc-type=auto) must be set within the eal field. There are two ways to use such a virtual device in a secondary process 1) Using the DPDK port number. Note however that the DPDK port number of virtual devices in the secondary process might not start from 0 and might hence have to be guessed e.g. if using 2 virtual devices in primary process (--vdev=net_ring0 --vdev=net_ring1) the port_id will be 0 and 1 in primary process and 2 & 3 in secondary process. 2) Using the port name, as defined in --vdev in the primary process. In this way, no [port] section must be defined, and the virtual port names are directly used within the "rx port" and "tx port" configuration e.g.: rx port=net_ring0 tx port=net_ring1 Limitations =========== There seems to be a PROX leak causing DPDK port id to increase when restarting the secondary process (causing the secondary process configuration through port id more difficult). As the primary process configures the port (including the number of rx and tx queues) based on its config file, the secondary process can't setup its own queues. Simple configurations (such as using gen or lat in primary, and swap in secondary) work as PROX allocates a RX queue even in gen mode and a TX queue even in lat mode. Better configuration/support for secondary process should be designed. The use of dpdk port names is only supported by PROX within "rx port" and "tx port". It is not supported by other configuration fields such as "tx ports from routing table". The use of dpdk port names in "rx port" and "tx port" is limited to only 1 port. Change-Id: Iaa606625da471403713a21df79d3ded4bb91b91e Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Added initial VLAN support with vdev devicesXavier Simonart1-1/+11
For kernel supported devices, add for vlan tag support This can be configured through port parameter: vlan tag=<vlan tag> If this parameter is set, a vlan tagged interface is created on top of the tap device This is only supported for vdev tap devices When sending (untagged) packet to the tap device (through socket) the tap should react in sending tagged packet Note that receiving in L3 mode (w/o tap support) a tagged packet is not yet supported. Change-Id: I363fa2f8d2341ac41ef23620222ece1d944bf336 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-05-29Add support for vdev tap devicesXavier Simonart1-2/+65
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-04-20Added support for DPDK 19.11Xavier Simonart1-1/+1
Change-Id: I58fa7a0ab7aaa27e9f9383f7995bb71bf0952618 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-01-29Added support for DPDK 19.08Xavier Simonart1-1/+1
Change-Id: I090bf8f1cd5a5d2dfa4f336bc66c46cc03d6c5bb Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2020-01-29Prepare for DPDK 19.08 supportXavier Simonart1-7/+7
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-17Merge "Increase the default number of rx and tx descriptors to 2K"Xavier Simonart1-6/+23
2019-10-13Increase the default number of rx and tx descriptors to 2KXavier Simonart1-6/+23
A high number of RX descriptor can be helpful in avoiding packet loss due to the core being interrupted. This commit increases the default number of descriptors from 256 to 2K. Those values are checked versus the minimum and maximum supported by the pmd. Number of mbufs (mempool size) have been updated n config files to support this default number of dsescriptors. The number of descriptors can still be overwritten by the config file. However those values must always remain within the limits reported by the pmd. Change-Id: I5f7999eca886dad68f3c0733da0d796bf4c06a56 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-10-13Disable TX checksum offload in some virtio casesXavier Simonart1-0/+7
Some OVS versions reports that they support UDP offload and no IPv4 offload, but fails when UDP offload is enabled. Hence, now, when virtio reports that it supports UDP checksum and no IPV4 checksum offload, we disable UDP checksum offload. Change-Id: I4f22f6be4d97b0aedf267ebeaa498c0dacef3317 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-10-10Update PROX to CRC STRIP default bahavior change in DPDKXavier Simonart1-0/+11
Change-Id: I7c3e2981692d823c86787b77d61190327d6448e4 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-10-09Add support for igmp and multicastXavier Simonart1-1/+14
Multicast can be enabled through configuration or through command line - Through configuration Add multicast=mcast_address (e.g. multicast=01:00:5e:01:02:03) in the port section - Through command line run enable multicast port_id mcast_address (e.g. enable multicast 1 01:00:5e:01:02:03) IGMP join message is sent unsollicited through command line: join igmp core_id task_id ip (e.g. join igmp 1 0 224.1.1.3) To enable swap answering IGMP Query (w/ IGMP Join) - Through configuration Add igmp ipv4=ip_address within the core/task section - Through command line join igmp core_id task_id ip (e.g. join igmp 1 0 224.1.1.3) (this will 1st initiate an unsollicated join, then answer any subsequent query) UDP/TCP packets received on a multicast address (224.0.0.0 => 239.255.255.255) are discarded To stop sending responses to IGMP query: leave igmp core_id task_id Change-Id: I3808ccabf3b38b5a1e10e1b044db63aa05bcd7b5 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-10-08Fix setting mac address through [port] sectionXavier Simonart1-0/+3
MAC address can be configured through the [port] section. However this had only some effect on packets being transmitted. For instance it was used to set the src mac address by the generator. It had no effect on packets reception: when not in promiscuous mode only the packets with the MAC originally set by the HW were received. Now, when not in promiscuous mode, only packets with MAC as defined in [port] section will be received. Change-Id: I064817bf6727d098e89fbbb7a90412ed599f0fb6 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-10-08Fix setting rx and tx queue stats mappingXavier Simonart1-1/+3
rx_queue_stats_mapping and tx_queue_stats_mapping were called unrespective of the number of active queues, and failing on all unactive queues. this caused lot of errros in prox.log Change-Id: I15ecb7adfb562caff8efb0eb24c341a3ba354571 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-10-08Support for recent GCC compilerXavier Simonart1-4/+4
This is required for instance on gcc (GCC) 8.2.1 20180905 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com> Change-Id: Id86de5d39d77c5cbf168cc51434f436f84376a4c
2019-04-15PROX: fix minimum rx buffer size used within generatorXavier Simonart1-0/+3
Different PMD have different requirements for minimum rx buffer size. vmxnet3 has (in DPDK 18.08) requires minimum 1518 + 128 (RTE_PKTMBUF_HEADROOM). Change-Id: I327ae5b8dcf7eef8dd71fb4e2f0603b9bab6e1d3 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-03-06PROX generator: performance optimization (2/4)Xavier Simonart1-22/+20
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-02-20Use link speed from device capability instead of negotiated speedaXavier Simonart1-10/+61
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>
2019-01-23Configure RSS hashing to IP/UDP and check for with PMD supportXavier Simonart1-2/+9
RSS was enabled when rss=yes is set in the configuration or when multiqueue is being used. But when RSS was enabled the types of packets on which RSS hashing was applied might not be supported by the PMD, as almost every PMD supported a different set of packets. Change-Id: I1d9516da61df7ef18c1d6953879ee15e33fca077 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2019-01-23Clean up port initializationXavier Simonart1-77/+68
Change-Id: Ia9df816d522e5db460d9129109525d5d345d997f Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-12-06Merge "Fix potential crash when getting device info"Deepak S1-10/+12
2018-12-05Add support for VLAN insert and strippingXavier Simonart1-0/+2
JIRA: SAMPLEVNF-149 VLAN can be enabled on a port by adding "vlan=yes" in the port section. When VLAN is enabled on a port, then DEV_RX_OFFLOAD_VLAN_STRIP and DEV_TX_OFFLOAD_VLAN_INSERT are enabled (if device supports it). This will cause VLAN to be stripped from any packets received with the proper tag, and VLAN to be added for any packets being transmitted. The VLAN ID themselves are configured through the physical function using something like (where ens801f1 isthe PF): ip link set ens801f1 vf 0 vlan 1111 Change-Id: I945c87b0c18565da479ecaa08e5ffce91232a7ce Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-11-04Fix potential crash when getting device infoXavier Simonart1-10/+12
In some cases, like when using virtual functions, getting device info return a NULL device, which was potentially causing a crash. Change-Id: Icc65f35bb54cd7d9bd8d837b3d6ec7ebb48b7c5e Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-10-31Support for DPDK 18.05 and DPDK 18.08Xavier Simonart1-20/+191
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-09-04Workaround DPDK net/virtio queue setup issuePatrice Buriez1-14/+14
JIRA: SAMPLEVNF-127 PROX was crashing in the VM with vector mode enabled and multiple OVS queues. This was not really a PROX bug, but a DPDK issue, which has been fixed by DPDK commit https://git.dpdk.org/dpdk/commit/?id=efc83a1e7fc3 This "net/virtio: fix queue setup consistency" is included in DPDK 17.11 and subsequent versions, and has been backported into: - DPDK 16.11.4: https://git.dpdk.org/dpdk-stable/commit/?h=16.11&id=516447a5056c - DPDK 17.08.1: https://git.dpdk.org/dpdk-stable/commit/?h=17.08&id=907fe4fc263e This means the fix is not included into any DPDK 17.02.x used by NSB. Fortunately, a simple workaround consists of calling rte_eth_tx_queue_setup() before rte_eth_rx_queue_setup(). This change implements this simple workaround, in order to make PROX work, even with unfixed DPDK versions. Change-Id: I818e9bb812babe023c6b7225c8b9769a359d9bec Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
2018-07-26Initial support for DPDK 18.05Xavier Simonart1-3/+10
This patch makes PROX compile with DPDK 18.05. However some features are disabled or will not work as expected such as: "mem info" command "police" mode Those will need to be fixed later (see DPDK1805 within code). Change-Id: Ie7d72f6ab3db68bc093c42d60d125fe86f8fbda7 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com> Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
2018-05-25Increase default mbuf size and code simplification/cleanupXavier Simonart1-6/+24
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-26Fix crc offloads.Xavier Simonart1-4/+4
When configuring a port, prox configures queue flags. For historitical reasons, offloads had to be disabled on some pmds. There is now an API to query the ports and gets their capabilities. This fix sets now the flags based on the capabilities, and not the driver name. Change-Id: Ic72d15001992f26910f653c70d31e4381fff8089 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-04-15Add support for reception of jumbo framesXavier Simonart1-6/+4
Jumbo frames are now supported through the addition of a "mtu" parameter of the port in the config file. Setting the mtu to a value higher than 1500 bytes will enable the reception of jumbo frames. In addition, the rte_eth_dev_set_mtu is now set for all pmds. Finally, setting mbuf_size does not set MEMPOOL_F_NO_SPREAD anymore. This option was only used for pure debugging. Big packets can be received using two ways - Using multiple "small" mbufs, i.e. around 2K. This is the default. - Using one big mbuf holding the whole packet. This can be enabled by setting a parameter mbuf_size in the receiving core configuration Change-Id: Idd60ad31f41c89f9522dff4d894af2696b7a2ea1 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-01-16Integrate irq mode into PROX (support display and command line)Xavier Simonart1-3/+5
irq mode can be used to show how a core is interrupted by other tasks. This mode does not handle packets. It only loops reading tsc. When the difference between two consecutive calls to rdtsc() is high then it means the core was interrupted. This task implementes the display, so that we can see a histogram of interrupts as well as the maximum, per core. Command line is also supported, through "show irq buckets" (too show the intervals of each buckets, in micrcoseconds), and the stats command line (showing the number of items in each buckets and the max).. Change-Id: I153cc3deaa7b86ae2776ea44e46ef9ecfd116992 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2018-01-04Add support for DPDK 17.11Xavier Simonart1-2/+19
Change-Id: I5611ead4b61b23d6c1c983852e8c75619e08ecf9 Signed-off-by: Xavier Simonart <xavier.simonart@intel.com>
2017-10-25Merge changes from PROX-v041Patrice Buriez1-2/+13
Change-Id: Ie6d4e7ce22c27967117a446626f5923643397812 Signed-off-by: Patrice Buriez <patrice.buriez@intel.com>
2017-09-12Enabling Prox to be compatible with Titanium CloudDeepak S1-0/+1
Change-Id: I65e8b2d1cea2a1edfa738671e460b6a0170d3363 Signed-off-by: Deepak S <deepak.s@linux.intel.com>
2017-07-14Adding PROX(Packet pROcessing eXecution engine) VNF to sampleVNFDeepak S1-0/+473
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>