04/12/2019 16:29, Jerome Tollet (jtollet): > Hi Thomas, > I strongly disagree with your conclusions from this discussion: > > 1) Yes, VPP made the choice of not being DPDK dependent BUT certainly not at > the cost of performance. (It's actually the opposite ie AVF driver)
I mean performance cost when using DPDK from VPP. Of course there is no cost when using native VPP driver. > 2) VPP is NOT exclusively CPU centric. I gave you the example of crypto > offload based on Intel QAT cards (lookaside). There are other examples > (lookaside and inline) Yes there is QAT lookaside and can be others. But you pay the cost of buffer conversion each time you use a DPDK driver. > 3) Plugins are free to use any sort of offload (and they do). I understand from Ole Troan that the focus is more on generic features, so you avoid hardware limitations. > Le 04/12/2019 15:19, « vpp-dev@lists.fd.io au nom de Thomas Monjalon » > <vpp-dev@lists.fd.io au nom de tho...@monjalon.net> a écrit : > > 03/12/2019 20:01, Damjan Marion: > > On 3 Dec 2019, at 17:06, Thomas Monjalon wrote: > > > 03/12/2019 13:12, Damjan Marion: > > >> On 3 Dec 2019, at 09:28, Thomas Monjalon wrote: > > >>> 03/12/2019 00:26, Damjan Marion: > > >>>> On 2 Dec 2019, at 23:35, Thomas Monjalon wrote: > > >>>>> 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... > > As stated below, I take this feedback, thanks. > However it won't change VPP choice of not using rte_mbuf natively. > > [...] > > >> 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). > > > > Nice marketing pitch for your company :) > > I guess you mean Mellanox has a good offloads offering. > But my point is about the end of Moore's law, > and the offload trending of most of device vendors. > However I truly respect the choice of avoiding device offloads. > > > > 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. > > > > Yes, DPDK is centre of the universe/ > > DPDK is where most of networking devices are supported in userspace. > That's all. > > > > So Dear Thomas, I can continue this discussion forever, but that is not > something I'm going to do as it started to be trolling contest. > > I agree > > > I can understand that you may be passionate about you project and that > you maybe think that it is the greatest thing after sliced bread, but please > allow that other people have different opinion. Instead of giving the lessons > to other people what they should do, if you are interested for dpdk to be > better consumed, please take a feedback provided to you. I assume that you > are interested as you showed up on this mailing list, if not there was no > reason for starting this thread in the first place. > > Thank you for the feedbacks, this discussion was required: > 1/ it gives more motivation to improve EAL API > 2/ it confirms the VPP design choice of not being DPDK-dependent (at a > performance cost) > 3/ it confirms the VPP design choice of being focused on CPU-based > processing
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14800): https://lists.fd.io/g/vpp-dev/message/14800 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] -=-=-=-=-=-=-=-=-=-=-=-
