> > 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. > > Why not comparing with DPDK AVF?
i40e was simply there from day one... > >> Thanks for native AVF driver and new buffer management code we managed to go >> bellow 100 clocks per packet for the whole ipv4 routing base test. >> >> My understanding is that performance difference is caused by 4 factors, but >> i cannot support each of them with number as i never conducted detailed >> testing. >> >> - less work done in driver code, as we have freedom to cherrypick only data >> we need, and in case of DPDK, PMD needs to be universal > > For info, offloads are disabled by default now in DPDK. Good to know... > >> - no cost of medatata processing (rtr_mbuf -> vlib_buffer_t) conversion >> >> - less pressure on cache (we touch 2 cacheline less with native driver for >> each packet), this is specially observable on smaller devices with less cache >> >> - faster buffer management code >> >> >>> I'm sure there would be some benefits of switching VPP to natively use >>> the DPDK mbuf allocated in mempools. >> >> I dont agree with this statement, we hawe own buffer management code an we >> are not interested in using dpdk mempools. There are many use cases where we >> don't need DPDK and we wan't VPP not to be dependant on DPDK code. >> >>> What would be the drawbacks? >> >> >>> Last time I asked this question, the answer was about compatibility with >>> other driver backends, especially ODP. What happened? >>> DPDK drivers are still the only external drivers used by VPP? >> >> No, we still use DPDK drivers in many cases, but also we >> have lot of native drivers in VPP those days: >> >> - intel AVF >> - virtio >> - vmxnet3 >> - rdma (for mlx4, mlx5 an other rdma capable cards), direct verbs for mlx5 >> work in progess >> - tap with virtio backend >> - memif >> - marvlel pp2 >> - (af_xdp - work in progress) >> >>> When using DPDK, more than 40 networking drivers are available: >>> https://core.dpdk.org/supported/ >>> After 4 years of Open Source VPP, there are less than 10 native drivers: >>> - virtual drivers: virtio, vmxnet3, af_packet, netmap, memif >>> - hardware drivers: ixge, avf, pp2 >>> And if looking at ixge driver, we can read: >>> " >>> This driver is not intended for production use and it is unsupported. >>> It is provided for educational use only. >>> Please use supported DPDK driver instead. >>> " >> >> yep, ixgbe driver is not maintained for long time... >> >>> 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. 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... > > >> Good example what will be good fit for us is rdma-core library, it allows >> you to programm nic and fetch packets from it in much more lightweight way, >> and if you really want to have super-fast datapath, there is direct verbs >> interface which gives you access to tx/rx rings directly. >> >>> DPDK mbuf has dynamic fields now; it can help to register metadata on >>> demand. >>> And it is still possible to statically reserve some extra space for >>> application-specific metadata in each packet. >> >> I don't see this s a huge benefit, you still need to call rte_eal_init, you >> still need to use dpdk mempools. Basically it still requires adoption of the >> whole dpdk ecosystem which we don't want... >> >> >>> Other improvements, like meson packaging usable with pkg-config, >>> were done during last years and may deserve to be considered. >> >> I'm aware of that but I was not able to found good justification to invest >> time to change existing scripting to move to meson. As typically vpp >> developers doesn't need to compile dpdk very frequently current solution is >> simply good enough... — Damjan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14762): https://lists.fd.io/g/vpp-dev/message/14762 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] -=-=-=-=-=-=-=-=-=-=-=-
