Hi Jerome, Thanks for the clarification
Regards, Nitin > -----Original Message----- > From: Jerome Tollet (jtollet) <jtol...@cisco.com> > Sent: Wednesday, December 4, 2019 11:30 PM > To: Nitin Saxena <nsax...@marvell.com>; Thomas Monjalon > <tho...@monjalon.net>; Damjan Marion <dmar...@me.com> > Cc: vpp-dev@lists.fd.io > Subject: [EXT] Re: [vpp-dev] efficient use of DPDK > > External Email > > ---------------------------------------------------------------------- > Hi Nitin, > > I am not necessarily speaking about Inline IPSec. I was just saying that VPP > lets you the choice to do both inline and lookaside types of offload. > > Here is a public example of inline acceleration: > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.intel.com_content_dam_www_programmable_us_en_pdfs_litera > ture_wp_wp-2D01295-2Dhcl-2Dsegment-2Drouting-2Dover-2Dipv6- > 2Dacceleration-2Dusing-2Dintel-2Dfpga-2Dprogrammable-2Dacceleration- > 2Dcard- > 2Dn3000.pdf&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=S4H7jibYAtA5YO > vfL3IkGduCfk9LbZMPOAecQGDzWV0&m=cegWttxd0q- > zJRoby35GO4izb4G9cJy-87BbbFqgeu8&s=7bej1I- > Gyc_F0C_RWhtavWmKiyNbC1m-0tkkrG005r0&e= > > Jerome > > > > Le 04/12/2019 18:19, « Nitin Saxena » <nsax...@marvell.com> a écrit : > > > > Hi Jerome, > > > > I have query unrelated to the original thread. > > > > >> There are other examples (lookaside and inline) > > By inline do you mean "Inline IPSEC"? Could you please elaborate what you > meant by inline offload in VPP? > > > > Thanks, > > Nitin > > > > > -----Original Message----- > > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Jerome > Tollet > > > via Lists.Fd.Io > > > Sent: Wednesday, December 4, 2019 9:00 PM > > > To: Thomas Monjalon <tho...@monjalon.net>; Damjan Marion > > > <dmar...@me.com> > > > Cc: vpp-dev@lists.fd.io > > > Subject: [EXT] Re: [vpp-dev] efficient use of DPDK > > > > > > External Email > > > > > > ---------------------------------------------------------------------- > > > 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) > > > 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) > > > 3) Plugins are free to use any sort of offload (and they do). > > > > > > Jerome > > > > > > 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 (#14806): https://lists.fd.io/g/vpp-dev/message/14806 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] -=-=-=-=-=-=-=-=-=-=-=-
