03/12/2019 13:12, Damjan Marion: > > On 3 Dec 2019, at 09:28, Thomas Monjalon <tho...@monjalon.net> wrote: > > 03/12/2019 00:26, Damjan Marion: > >> > >> Hi THomas! > >> > >> Inline... > >> > >>>> On 2 Dec 2019, at 23:35, Thomas Monjalon <tho...@monjalon.net> wrote: > >>> > >>> Hi all, > >>> > >>> VPP has a buffer called vlib_buffer_t, while DPDK has rte_mbuf. > >>> Are there some benchmarks about the cost of converting, from one format > >>> to the other one, during Rx/Tx operations? > >> > >> We are benchmarking both dpdk i40e PMD performance and native VPP AVF > >> driver performance and we are seeing significantly better performance with > >> native AVF. > >> If you taake a look at [1] you will see that DPDK i40e driver provides > >> 18.62 Mpps and exactly the same test with native AVF driver is giving us > >> arounf 24.86 Mpps. [...] > >> > >>> So why not improving DPDK integration in VPP to make it faster? > >> > >> Yes, if we can get freedom to use parts of DPDK we want instead of being > >> forced to adopt whole DPDK ecosystem. > >> for example, you cannot use dpdk drivers without using EAL, mempool, > >> rte_mbuf... rte_eal_init is monster which I was hoping that it will > >> disappear for long time... > > > > You could help to improve these parts of DPDK, > > instead of spending time to try implementing few drivers. > > Then VPP would benefit from a rich driver ecosystem. > > Thank you for letting me know what could be better use of my time.
"You" was referring to VPP developers. I think some other Cisco developers are also contributing to VPP. > At the moment we have good coverage of native drivers, and still there is a > option for people to use dpdk. It is now mainly up to driver vendors to > decide if they are happy with performance they wil get from dpdk pmd or they > want better... Yes it is possible to use DPDK in VPP with degraded performance. If an user wants best performance with VPP and a real NIC, a new driver must be implemented for VPP only. Anyway real performance benefits are in hardware device offloads which will be hard to implement in VPP native drivers. Support (investment) would be needed from vendors to make it happen. About offloads, VPP is not using crypto or compression drivers that DPDK provides (plus regex coming). VPP is a CPU-based packet processing software. If users want to leverage hardware device offloads, a truly DPDK-based software is required. If I understand well your replies, such software cannot be VPP.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14767): https://lists.fd.io/g/vpp-dev/message/14767 Mute This Topic: https://lists.fd.io/mt/65218320/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
