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] > 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] > https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________ vpp-dev mailing list [email protected] https://lists.fd.io/mailman/listinfo/vpp-dev
