Dear Nitin, i already provided my view in previous email. But that’s just my humble opinion. I don't have access to that hardware or free cycles to invest into this topic.
Will let others to comment…. — Damjan > On 2 Sep 2019, at 19:14, Nitin Saxena <nsax...@marvell.com> wrote: > > Hi Damjan and others, > > I would appreciate if we continue to have discussion about pros and cons of > the patch we pushed for Marvell OCTEON TX2 plugin. With our DPDK based > custom plugin we have achieved benefits of both worlds. > Leverage nice abstraction of DPDK APIs > Specific optimizations for VPP by removing rte_mbuf() dependency > > Just to re-iterate we want to have plugin based on custom DPDK because > The custom plugin allow us to achieve what a VPP native driver plugin can do. > Currently both INPUT node (octeontx2-input) and Tx node takes ~35 cycles each > and there is further scope for optimization. > The plugin does not conflict with existing dpdk plugin (as cmake require > “libmarvelldpdk” library check to enable this plugin compilation). > We are open to provide patches for review > If required we can host custom library publicly > All custom changes are restricted to PMD and there is no change in rte > library. > > As things stand out we have two alternatives to upstream this plugin in VPP > Add native support > Adding native ethdev driver support in VPP is a gigantic effort.(See: > https://git.dpdk.org/dpdk/tree/drivers/net/octeontx2 > <https://git.dpdk.org/dpdk/tree/drivers/net/octeontx2>) > This mammoth task is not going to be meaningful for us as we are able to > achieve similar performance with our custom DPDK plugin > We also have plans to use other well defined abstractions of DPDK like > rte_security()/rte_flow()/rte_tm() etc. > > Extend existing DPDK plugin for OCTEON TX2 > By doing so we will loose the cycles we have achieved by removing rte_mbuf > both in Rx/Tx path > Separate plugin make sense for us as we have plans to use optimized version > of other DPDK’s abstraction APIs like > i. > rte_security (https://doc.dpdk.org/guides/prog_guide/rte_security.html > <https://doc.dpdk.org/guides/prog_guide/rte_security.html>) > > So help us in understanding what can we do to upstream this plugin. > Appreciate if questions in following mail can be answered. > > Thanks, > Nitin > > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io > <mailto:vpp-dev@lists.fd.io>> On Behalf Of Nitin Saxena > Sent: Tuesday, August 20, 2019 3:31 PM > To: Damjan Marion <dmar...@me.com <mailto:dmar...@me.com>> > Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>; Narayana Prasad Raju > Athreya <pathr...@marvell.com <mailto:pathr...@marvell.com>> > Subject: Re: [EXT] [vpp-dev] Marvell OCTEONTx2 plugin > > Hi Damjan, > > See my response inline > > Thanks, > Nitin > > From: Damjan Marion <dmar...@me.com <mailto:dmar...@me.com>> > Sent: Tuesday, August 20, 2019 12:24 AM > To: Nitin Saxena <nsax...@marvell.com <mailto:nsax...@marvell.com>> > Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > Subject: Re: [EXT] [vpp-dev] Marvell OCTEONTx2 plugin > > Dear Nitin, > > Here is my view on this: > > - All VPP dependencies should be open source and freely available software, > afaik access to Marvell SDK is restricted to NDA customers and that is no go > [Nitin]: Got it. By dependency do you mean compile-time dependencies or > run-time as well? Could you please clarify following doubts (None of them > applies to my patch submission though) > If I have firmware that is loaded onto hardware and that would be completely > closed-source(and part of Marvell SDK), would such firmware violate the > dependency policy? > If I have a kernel module that is part of the Marvell SDK. Can VPP issue > system calls to such a module, or would it violate the dependency policy you > mentioned? > If I use dlopen to operate with a proprietary library in Marvell SDK, would > that violate the dependency policy? > > - preferred way to add device driver support in VPP is native one, typically > provided as plugin and such driver can be linked to external library if it is > open source. We already do that with marvel MUSDK and rdma-core. Nice feature > of both libraries is that they provide way to access descriptors directly > without metadata conversion into intermediate data structure (e.g. dpdk > rte_mbuf). > > - we are fine to have out-of-tree patches on top of DPDK as long as they are > limited to providing new PMD and not altering common dpdk code. > [Nitin]: Yes my intent was same. I can share DPDK patches over email so you > can take a look and let me know your views on that. Let me know if that is ok. > > - Having separate plugin with own "special" version of DPDK is something I > don't like. You should decide either to go with dpdk pmd and extend existing > dpdk plugin, or create native driver without dpdk code. > [Nitin]: I tried to think along these lines but I could not contemplate all > ramifications beyond OCTEONTX2. Perhaps you can look at my patches and see > whether what you are suggesting is possible with the existing plugin? > > Thanks, > > Damjan > > > On 19 Aug 2019, at 20:03, Nitin Saxena <nsax...@marvell.com > <mailto:nsax...@marvell.com>> wrote: > > Hi Damjan, > > Thanks for comment. libmarvelldpdk is not intended to be a closed source and > is part of Marvell SDK for our customers. Would it be ok to provide patches > against DPDK release (from dpdk.org <http://dpdk.org/>) OR does it need to be > hosted publicly? > > Thanks, > Nitin > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io > <mailto:vpp-dev@lists.fd.io>> on behalf of Damjan Marion via Lists.Fd.Io > <dmarion=me....@lists.fd.io <mailto:dmarion=me....@lists.fd.io>> > Sent: Monday, August 19, 2019 9:30 PM > To: Nitin Saxena <nsax...@marvell.com <mailto:nsax...@marvell.com>> > Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io > <mailto:vpp-dev@lists.fd.io>> > Subject: [EXT] Re: [vpp-dev] Marvell OCTEONTx2 plugin > > External Email > > Dear Nitin, > > Where we can find “libmarvelldpdk”? Google search doesn’t show single > occurrence. > > We don’t support contributions linked to closed source libraries… > > — > Damjan > > > > > > On 19 Aug 2019, at 16:53, Nitin Saxena <nsax...@marvell.com > <mailto:nsax...@marvell.com>> wrote: > > Hi, > > Following is the link for README.md > https://gerrit.fd.io/r/#/c/vpp/+/21394/1/src/plugins/octeontx2/README.md > <https://gerrit.fd.io/r/#/c/vpp/+/21394/1/src/plugins/octeontx2/README.md> > > Thanks, > Nitin > From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io > <mailto:vpp-dev@lists.fd.io>> On Behalf Of Nitin Saxena > Sent: Monday, August 19, 2019 8:21 PM > To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > Cc: Narayana Prasad Raju Athreya <pathr...@marvell.com > <mailto:pathr...@marvell.com>> > Subject: [EXT] [vpp-dev] Marvell OCTEONTx2 plugin > > External Email > Hi Maintainers, > > I have pushed patch for Marvell OCTEON TX2 driver plugin: > https://gerrit.fd.io/r/#/c/vpp/+/21394/ > <https://gerrit.fd.io/r/#/c/vpp/+/21394/> > > Appreciate your feedback on the patch. > > Thanks, > Nitin > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#13786): https://lists.fd.io/g/vpp-dev/message/13786 > <https://lists.fd.io/g/vpp-dev/message/13786> > Mute This Topic: https://lists.fd.io/mt/32945036/675642 > <https://lists.fd.io/mt/32945036/675642> > Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub > <https://lists.fd.io/g/vpp-dev/unsub> [dmar...@me.com > <mailto:dmar...@me.com>] > -=-=-=-=-=-=-=-=-=-=-=- > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#13791): https://lists.fd.io/g/vpp-dev/message/13791 > <https://lists.fd.io/g/vpp-dev/message/13791> > Mute This Topic: https://lists.fd.io/mt/32958379/675642 > <https://lists.fd.io/mt/32958379/675642> > Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub > <https://lists.fd.io/g/vpp-dev/unsub> [dmar...@me.com > <mailto:dmar...@me.com>] > -=-=-=-=-=-=-=-=-=-=-=- > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#13883): https://lists.fd.io/g/vpp-dev/message/13883 > <https://lists.fd.io/g/vpp-dev/message/13883> > Mute This Topic: https://lists.fd.io/mt/32958934/675642 > <https://lists.fd.io/mt/32958934/675642> > Group Owner: vpp-dev+ow...@lists.fd.io <mailto:vpp-dev+ow...@lists.fd.io> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub > <https://lists.fd.io/g/vpp-dev/unsub> [dmar...@me.com > <mailto:dmar...@me.com>] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13884): https://lists.fd.io/g/vpp-dev/message/13884 Mute This Topic: https://lists.fd.io/mt/32958934/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
