Re: [vpp-dev] Lots of patches failing like this... (CentOS)

Folks, I just merged this patch, so you might want to rebase your patches to avoid this snafu. Thanks, -daw- On 9/17/19 3:41 PM, Ed Kern via Lists.Fd.Io wrote: Ok so looks like centos obsoleted the packages python36-devel in favor of the name python3-devel python36-pip in favor of the name

Re: [vpp-dev] Lots of patches failing like this... (CentOS)

Ok so looks like centos obsoleted the packages python36-devel in favor of the name python3-devel python36-pip in favor of the name python3-pip So all the centos builds barfed because it had the ‘old’ name in required list https://gerrit.fd.io/r/c/vpp/+/22109 is verifying and the mighty wallace

Re: [vpp-dev] gprof?

> On Sep 17, 2019, at 11:21 AM, Damjan Marion via Lists.Fd.Io > wrote: > > > >> On 17 Sep 2019, at 17:12, Christian Hopps wrote: >> >> >> >>> On Sep 17, 2019, at 3:56 AM, Benoit Ganne (bganne) via Lists.Fd.Io >>> wrote: >>> > AFAIK the default for x86_64 is to omit frame pointer

[vpp-dev] Assert verifying node graph construction around ip4-arp.

Hi vpp-dev, I'm hitting an assert in vlib_next_frame_change_ownership (vlib/main.c) ASSERT (vec_len (node->next_nodes) == node_runtime->n_next_nodes); I added some code to see what was going on #ifdef CLIB_ASSERT_ENABLE if (vec_len (node->next_nodes) != node_runtime->n_next_nodes)

Re: [vpp-dev] P4 INT( Inband Network Telemetry)

I concur with Justin. I am hoping that with IETF106 we may get closer to WGLC for the IOAM data draft. I have it in my TODO list to bring the VPP IOAM IPv6 implementation pre-allocated trace option on par with the draft. POT and Sequence number E2E option do match the IETF draft. Thanks,

Re: [vpp-dev] P4 INT( Inband Network Telemetry)

Davi, The introduction of IOAM namespaces was the big addition and came with version 4 of the draft. Since then, some other (small) modifications were also added here and there. Last time I talked to Shwetha during IETF, she told me it was planned to update vpp/ioam to a more recent version

Re: [vpp-dev] How to compile VPP with external(prebuilt) DPDK #vpp

You can just invoke cmake directly and it should find installed dpdk libraries. I.e. mkdir build cd build cmake -Gninja /path/to/vpp ninja You can also use standard cmake way to specify directories... — Damjan > On Sep 17, 2019, at 10:13 AM, Jaemin Park wrote: > > Hello, > > I'd like to

Re: [vpp-dev] Issue with DPDK 19.08 / i40e driver

Hi Aloÿs Thanks for fixing this issue so fast. ☺ - Best Regards, Sun, Chenmin From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Aloys Augustin (aloaugus) via Lists.Fd.Io Sent: Tuesday, September 17, 2019 4:16 PM To: Sun, Chenmin Cc:

Re: [vpp-dev] Issue with DPDK 19.08 / i40e driver

Hi Chenmin, Thanks a lot for digging into this. I found an old issue, VPP-133: https://jira.fd.io/browse/VPP-133 , that looks very similar to this bug. Increasing the stack size allocated to CLI processes resolves the issue, so it looks like the inlining

[vpp-dev] How to compile VPP with external(prebuilt) DPDK #vpp

Hello, I'd like to compile VPP(ver. 20.01) by using external (prebuilt & installed) DPDK. However, it seems that some configurations such as vpp_dpdk_inc_dir and others are removed since cmake is used in VPP. *Is there any way to use external DPDK for compiling VPP(ver. 20.01)?* The followings

Re: [vpp-dev] gprof?

>> AFAIK the default for x86_64 is to omit frame pointer >> for optimized builds so you probably do not have it in most cases in VPP >> builds (but I did not check). >> So when perf tries to interpret random data as frame pointer, this is >> what you get :) >> The most reliable (but slowest)