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
