[vpp-dev] Trunk ports with VPP

Hi,     i am trying to achieve trunck ports with VPP using following documentation https://wiki.fd.io/view/VPP/Interconnecting_vRouters_with_VPP#Create_TRUNK_ports only difference is that i am trying this with host interfaces connected to netns instance. However packet egressing on this trunk

Re: [vpp-dev] Poor L3/L4 Performance

As discussed off-list: please stick to best-practice coding patterns. Single-packet frames simply cannot perform, etc. Thanks… Dave From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Alessio Silvestro Sent: Monday, September 25, 2017 10:13 AM To:

Re: [vpp-dev] Static Route Data API Data Structures

Hi Jon, Some answers inline. Thanks, neale -Original Message- From: Jon Loeliger Date: Thursday, 21 September 2017 at 16:42 To: "Neale Ranns (nranns)" Cc: vpp-dev Subject: Re: [vpp-dev] Static Route Data API Data Structures

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

> I don't know about CSIT, but "make test" tests use python API bindings, > which internally uses old C API bindings (vapiclient). Unless we want > to remove old C API, there is little motivation to rework python API > binding as it contains more or less the same logic as the new C/C++ API >

Re: [vpp-dev] Problem in ARP reply

Hi Andrew, Can you describe your use case/requirements in more detail please. Addresses on the subnet the ARP request arrives on, the ARP proxy range configured and a packet trace indicating what you consider to be incorrect behaviour. Thanks, neale From: on

Re: [vpp-dev] Poor L3/L4 Performance

Dear Alessio, It is hard to guess where is the problem out of your description, but I would not be surprised that your implementation of those graph nodes is not properly performance tuned. One missing prefetch can hurt performance really badly. If you are able to share your code I can take a

[vpp-dev] [FD.io Helpdesk #45750] Spurious patch verification failure (gerrit 8400)

Switching to the new flavors appears to have resolved this issue. Thank you, Vanessa On Wed Sep 13 15:09:49 2017, valderrv wrote: > We do see intermittent slow response times from Nexus. We are > investigating the cause. > > On Wed Sep 13 09:56:20 2017, dbarach wrote: > > See gerrit

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

I thought of a solution, but it a purely technological one that ignores any business relationship details, as they are above my pay grade: if VPP were part of the EPEL distribution rather than directly part of RHEL/CentOS, then there would be no problems! Burt On Mon, Sep 25, 2017 at 7:31 AM,

[vpp-dev] Poor L3/L4 Performance

Dear all, I am performing some experiments on VPP in order to get some performance metrics for specific applications. I am working on vpp v17.04.2-2. In order to have a baseline of my system, I run L2 XConnect (XC) as in [ https://perso.telecom-paristech.fr/~drossi/paper/vpp-bench-techrep.pdf].

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

Posted from iPhone. Forgive top posting, and terse writing style.. --Thomas F Herbert SDN Group Office of Technology Red Hat > On Sep 25, 2017, at 1:03 PM, Klement Sekera -X (ksekera - PANTHEON > TECHNOLOGIES at Cisco) wrote: > > Quoting Thomas F Herbert (2017-09-25

Re: [vpp-dev] ipv6 lookup rate

Any inputs on this is appreciated Thanks, Pragash Vijayaragavan Grad Student at Rochester Institute of Technology email : pxv3...@rit.edu ph : 585 764 4662 On Thu, Sep 21, 2017 at 4:50 PM, Pragash Vijayaragavan wrote: > Hi Guys, > > We are working on ipv6 lookup rate in

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

Quoting Thomas F Herbert (2017-09-25 13:31:55) >On 09/25/2017 05:02 AM, Marco Varlese wrote: > > Thanks for the thorough explanation Klement!Based on that, I think (2) is > still the better option for the current situation... > > Tom, how would that sound to you? > > > "Klement Sekera

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

On 09/25/2017 05:02 AM, Marco Varlese wrote: Thanks for the thorough explanation Klement!Based on that, I think (2) is still the better option for the current situation... Tom, how would that sound to you? "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)"

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

Thanks for the thorough explanation Klement!Based on that, I think (2) is still the better option for the current situation... Tom, how would that sound to you? >>> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" >>> 09/25/17 10:40 AM >>> Quoting Marco

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

Quoting Marco Varlese (2017-09-25 10:26:50) > Hi Klement, > > >>> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" > >>> 09/25/17 9:33 AM >>> > > At the time of creating this patch, epel was part of Makefile and > > python34 was installed as dependency from that

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

Hi Klement, >>> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" >>> 09/25/17 9:33 AM >>> > At the time of creating this patch, epel was part of Makefile and > python34 was installed as dependency from that repo. > (see

Re: [vpp-dev] Problem with new c api patch commit 8f2a4ea merged on September 19

At the time of creating this patch, epel was part of Makefile and python34 was installed as dependency from that repo. (see https://gerrit.fd.io/r/#/c/6983/53/Makefile) At later time, the epel stuff disappeared and with it also the possibility to add python34 as a centos dependency - commit