Re: [EXT] [vpp-dev] Marvell OCTEONTx2 plugin

[Damjan Marion via Lists.Fd.Io]

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  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 
> )
> 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 
> )
>  
> 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   > On Behalf Of Nitin Saxena
> Sent: Tuesday, August 20, 2019 3:31 PM
> To: Damjan Marion mailto:dmar...@me.com>>
> Cc: vpp-dev@lists.fd.io ; Narayana Prasad Raju 
> Athreya mailto:pathr...@marvell.com>>
> Subject: Re: [EXT] [vpp-dev] Marvell OCTEONTx2 plugin
>  
> Hi Damjan,
>  
> See my response inline
>  
> Thanks,
> Nitin
>  
> From: Damjan Marion mailto:dmar...@me.com>> 
> Sent: Tuesday, August 20, 2019 12:24 AM
> To: Nitin Saxena mailto:nsax...@marvell.com>>
> Cc: 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 

Re: [EXT] [vpp-dev] Marvell OCTEONTx2 plugin

[Nitin Saxena]

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.

  1.  Leverage nice abstraction of DPDK APIs
  2.  Specific optimizations  for VPP by removing rte_mbuf() dependency

Just to re-iterate we want to have plugin based on custom DPDK because

  1.  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.
  2.  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

  1.  Add native support

  1.  Adding native ethdev driver support in VPP is a gigantic effort.(See: 
https://git.dpdk.org/dpdk/tree/drivers/net/octeontx2)
  2.  This mammoth task is not going to be meaningful for us as we are able to 
achieve similar performance with our custom DPDK plugin
  3.  We also have plans to use other well defined abstractions of DPDK like 
rte_security()/rte_flow()/rte_tm() etc.



  1.  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)


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  On Behalf Of Nitin Saxena
Sent: Tuesday, August 20, 2019 3:31 PM
To: Damjan Marion 
Cc: vpp-dev@lists.fd.io; Narayana Prasad Raju Athreya 
Subject: Re: [EXT] [vpp-dev] Marvell OCTEONTx2 plugin

Hi Damjan,

See my response inline

Thanks,
Nitin

From: Damjan Marion mailto:dmar...@me.com>>
Sent: Tuesday, August 20, 2019 12:24 AM
To: Nitin Saxena mailto:nsax...@marvell.com>>
Cc: 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)

  1.  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?
  2.  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?
  3.  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 
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) OR does it need to be 
hosted publicly?

Thanks,
Nitin

From: vpp-dev@lists.fd.io 

Re: [vpp-dev] how VAT work with Socket IP Address

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

>> See ssh -R / -L for example.

> Is this way not feasible?


It is feasible. In CSIT we use this (ssh -L) way,

although it took me some time to tune the ssh command

(so the tunnel is closed either on-demand or by timeout).


Here [0] is a part of the code composing the command,

in case you are interested in (complicated but working) example.


Also, some systems have fairly old ssh client,

according to [1] you need at least OpenSSH 6.7

(just on the app side, vpp side can have older ssh server).


Vratko.


[0] 
https://github.com/FDio/csit/blob/545216fdee77b0b9ddc8d5e8c0f2e5662cacea76/resources/libraries/python/PapiExecutor.py#L249-L255

[1] https://lwn.net/Articles/609321/



From: vpp-dev@lists.fd.io  on behalf of 
wei_sky2...@163.com 
Sent: Thursday, August 29, 2019 13:17
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] how VAT work with Socket IP Address

Thank you for your answer!
I want to develop an app on an PC,and VPP run on another PC,my app use VPP API 
to config VPP?Is this way not feasible?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13882): https://lists.fd.io/g/vpp-dev/message/13882
Mute This Topic: https://lists.fd.io/mt/33064939/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] CSIT-1908 draft report preview available, need help with two VPP performance regressions

[Maciek Konstantynowicz (mkonstan) via Lists.Fd.Io]

Hi,

A draft version of CSIT-1908 test and benchmarking report is available
on the CSIT master report link:

  https://docs.fd.io/csit/master/report/index.html

Most of the selected benchmarking tests have been completed including:

- All Xeon Skylake and Haswell NDR and PDR tests - all in draft report.
- Most of Atom/Denverton NDR and PDR tests - to be added to draft report.
- Most of Arm/Taishan NDR and PDR tests - to be added to draft report.

Comparison tables show some Skylake NDR/PDR throughput regressions and
progressions vs. CSIT-1904:

- 
https://docs.fd.io/csit/master/report/vpp_performance_tests/comparisons/current_vs_previous_release.html

Their latest analysis is tracked in the two CSIT gerrit commits:

- csit1908_perf_analysis_2n_skx.md: https://gerrit.fd.io/r/c/csit/+/21637/
- csit1908_perf_analysis_3n_skx.md: https://gerrit.fd.io/r/c/csit/+/21641/

Most have been root caused to CSIT and are being addressed in CSIT
before CSIT-1908 report is published on Wednesday 04-Sep.

Two VPP packet paths, l2 bridge-domain and iacl statefull have
suspected cause: *vpp binary code change affecting throughput*.
Any assistance with these two is appreciated.

Cheers,
-Maciek-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13881): https://lists.fd.io/g/vpp-dev/message/13881
Mute This Topic: https://lists.fd.io/mt/33111523/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-