The 'fix' in the Niantic vPMD was rejected upstream in DPDK for solid reasons - it causes a performance degradation in the Niantic vPMD .
I completely agree that this 'fix', fixing Niantic PType support is beneficial for the VPP workload, there is no argument with this upstream. The point was that this would be at the expense of every other workload that was not using PType support with the Niantic vPMD.
So this is a place where the requirements of VPP and other DPDK consumers may diverge. I think its a good example of where packaging projects are required to impartially service the needs of all consumers. I think every patch to DPDK (or indeed any open source project) needs to be reviewed on this basis.
That all said, we are looking at fixing the Niantic vPMD, in the same way we fixed the Fortville vPMD so hopefully we can have the best of both worlds.
Ray K On 08/12/2016 16:53, Ed Warnicke wrote:
Looping in the deb_dpdk and rpm_dpdk projects to see if we can work together on getting vpp out of the business of building DPDK (and DPDK packages) while still retaining the ability to quickly incorporate fixes like the one the Niantic driver. Ed On Thu, Dec 8, 2016 at 5:34 AM, Damjan Marion (damarion) <[email protected] <mailto:[email protected]>> wrote: I think it is right time to start discussing post 17.01 release developments and here I would like to propose some changes related to DPDK integration. I see a need for changes in 2 areas: 1) building DPDK as part of VPP build and patch management 2) moving DPDK related code (input node, tx, buffer, eal) to separate shared library ## Building DPDK as part of VPP build and patch management Unfortunately with DPDK 16.11 we are back in situation that we need to patch DPDK. Niantic/ixgbe vector PMD is not setting IP checksum offload flags so we need to rollback this change. Still, we don’t have any functional reasons not to compile/link VPP with unpatched DPDK. Going forward my proposal is: 1. removing dpdk build out of VPP git tree and depending on DPDK rpm/deb packages instead 2. Providing our optimized versions of those packages (ie. which include change to Niantic driver) 3. Users/developers can chose between using standard packages and optimized ones ## moving DPDK related code (input node, tx, buffer, eal) to separate shared library In 17.01 release I already did 1st step in that direction by removing almost all code which touches rte_mbuf and make handling of rte_mbuf duty of dpdk-input and dpdk-tx nodes. Reason for that is very simple, we want to have unique behavior independently of what interface types are used. So packets going in and out on vhost_user, af_packet, netmap or packet-generator interface should really don’t care about rte_mbuf. If packet arrives on vhost_user interface and goes out on dpdk, then dpdk-tx function will simply fix rte_mbuf. Next step which I would like to propose is moving DPDK related code to separate shared library (e.g. libvpp-dpdk). There are few reasons I have on my mind: * avoid building 2 different versions of VPP (vpp and vpp_lite), quite a lot of people are using vpp_lite in cases when they develop features and they simply don't have or don’t need access to physical interfaces * “make test” infrastructure is using vpp_lite * supporting ongoing efforts to use VPP with different libraries like ODP or Mellanox OFED. * avoid using weak references to rte_* functions which we have in the code today This change should be purely mechanical, it should not introduce any limitations in how we use DPDK today. Thanks, Damjan _______________________________________________ vpp-dev mailing list [email protected] <mailto:[email protected]> https://lists.fd.io/mailman/listinfo/vpp-dev <https://lists.fd.io/mailman/listinfo/vpp-dev> _______________________________________________ vpp-dev mailing list [email protected] https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________ vpp-dev mailing list [email protected] https://lists.fd.io/mailman/listinfo/vpp-dev
