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

[Dave Wallace]

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 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 promises to merge once it verifies..


Note to the future:

centos repo/maintainers did NOT rename either
python36-ply
or
python36-jsonschema

which are also req’s  in the Makefile just waiting for some random 
tuesday in the future to fail.


But for now the above gerrit should get centos moving again.

Ed



On Sep 17, 2019, at 11:32 AM, Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> wrote:


*13:00:41*[PostBuildScript] - Executing post build scripts.
*13:00:41*[vpp-verify-master-centos7] $ /bin/bash 
/tmp/jenkins653227054931649374.sh
*13:00:41*Build logs: href="https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-centos7/21710";>https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-centos7/21710
*13:00:41*/w/workspace/vpp-verify-master-centos7 
/w/workspace/vpp-verify-master-centos7/.archives

*13:00:41*Archiving **/build-root/*.rpm
*13:00:41*mv: cannot stat '**/build-root/*.rpm': No such file or 
directory

*13:00:41*Archiving **/build-root/*.deb
*13:00:41*mv: cannot stat '**/build-root/*.deb': No such file or 
directory

*13:00:41*Archiving **/dpdk/*.rpm
*13:00:41*mv: cannot stat '**/dpdk/*.rpm': No such file or directory
*13:00:41*Archiving **/dpdk/*.deb
*13:00:41*mv: cannot stat '**/dpdk/*.deb': No such file or directory
*13:00:41*/w/workspace/vpp-verify-master-centos7/.archives



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

View/Reply Online (#14009): https://lists.fd.io/g/vpp-dev/message/14009
Mute This Topic: https://lists.fd.io/mt/34180141/675079
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dwallac...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-


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

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

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

[Ed Kern via Lists.Fd.Io]

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 promises to merge once it verifies..


Note to the future:

centos repo/maintainers did NOT rename either
python36-ply
or
python36-jsonschema

which are also req’s  in the Makefile just waiting for some random tuesday in 
the future to fail.

But for now the above gerrit should get centos moving again.

Ed



On Sep 17, 2019, at 11:32 AM, Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> wrote:


13:00:41 [PostBuildScript] - Executing post build scripts.

13:00:41 [vpp-verify-master-centos7] $ /bin/bash 
/tmp/jenkins653227054931649374.sh

13:00:41 Build logs: https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-centos7/21710";>https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-centos7/21710

13:00:41 /w/workspace/vpp-verify-master-centos7 
/w/workspace/vpp-verify-master-centos7/.archives

13:00:41 Archiving **/build-root/*.rpm

13:00:41 mv: cannot stat '**/build-root/*.rpm': No such file or directory

13:00:41 Archiving **/build-root/*.deb

13:00:41 mv: cannot stat '**/build-root/*.deb': No such file or directory

13:00:41 Archiving **/dpdk/*.rpm

13:00:41 mv: cannot stat '**/dpdk/*.rpm': No such file or directory

13:00:41 Archiving **/dpdk/*.deb

13:00:41 mv: cannot stat '**/dpdk/*.deb': No such file or directory

13:00:41 /w/workspace/vpp-verify-master-centos7/.archives

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

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

Re: [vpp-dev] gprof?

[Christian Hopps]

> 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
> 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) should be dwarf. lbr should be the way
> to go on Intel Haswell and later.
 FWIW, this is being run on the Macchiatobin platform (i.e., aarch64
 cortex-A72). :)
>>> 
>>> My bad. Not sure what is going-on but it looks like gcc also omit fp by 
>>> default on aarch64: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
>>> Did you had a chance to try dwarf instead of fp?
>> 
>> It doesn't appear to be an option in my perf binary, unfortunately.
> 
> Wasn't much simpler to run "perf top" on the specific core and see where 
> cycles are spent?

This thread sort of forked I think. I was able to run "perf top" as well as 
"perf record" and get some results (indeed including specify a specific core). 
Additionally, I had some doubts about the results at the start of the thread 
b/c of the unexpected symbols that were present in the graph. Benoit has been 
making some suggestions on that (I think! :) front.

IOW I think I'm all good on the perf as far as it goes.

I still think it might be useful to have gprof work, especially if it just 
needs a little tweak somewhere to get working. :)

Thanks,
Chris.

> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14006): https://lists.fd.io/g/vpp-dev/message/14006
> Mute This Topic: https://lists.fd.io/mt/34128898/1826170
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [cho...@chopps.org]
> -=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: Message signed with OpenPGP
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] gprof?

[Damjan Marion via Lists.Fd.Io]

> 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
 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) should be dwarf. lbr should be the way
 to go on Intel Haswell and later.
>>> FWIW, this is being run on the Macchiatobin platform (i.e., aarch64
>>> cortex-A72). :)
>> 
>> My bad. Not sure what is going-on but it looks like gcc also omit fp by 
>> default on aarch64: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
>> Did you had a chance to try dwarf instead of fp?
> 
> It doesn't appear to be an option in my perf binary, unfortunately.

Wasn't much simpler to run "perf top" on the specific core and see where cycles 
are spent?

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

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

Re: [vpp-dev] gprof?

[Benoit Ganne (bganne) via Lists.Fd.Io]

>> My bad. Not sure what is going-on but it looks like gcc also omit fp by
>> default on aarch64: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
>> Did you had a chance to try dwarf instead of fp?
> It doesn't appear to be an option in my perf binary, unfortunately.

As a last resort, you can always rebuild VPP adding '-fno-omit-frame-pointer' 
in cflags.

ben
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] gprof?

[Christian Hopps]

> 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
>>> 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) should be dwarf. lbr should be the way
>>> to go on Intel Haswell and later.
>> FWIW, this is being run on the Macchiatobin platform (i.e., aarch64
>> cortex-A72). :)
> 
> My bad. Not sure what is going-on but it looks like gcc also omit fp by 
> default on aarch64: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
> Did you had a chance to try dwarf instead of fp?

It doesn't appear to be an option in my perf binary, unfortunately.

Thanks,
Chris.

> 
> Ben
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13997): https://lists.fd.io/g/vpp-dev/message/13997
> Mute This Topic: https://lists.fd.io/mt/34128898/1826170
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [cho...@chopps.org]
> -=-=-=-=-=-=-=-=-=-=-=-



signature.asc
Description: Message signed with OpenPGP
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

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

[Christian Hopps]

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)
 {
   clib_warning ("%s: in %s: vec_len (node->next_nodes) %u != %u 
node_runtime->n_next_nodes)",
 __FUNCTION__, node->name, vec_len (node->next_nodes), 
node_runtime->n_next_nodes);
   for (int i = 0; i < vec_len (node->next_nodes); i++)
   clib_warning ("%s: next %u: %u %s", __FUNCTION__, i, 
node->next_nodes[i],
 vlib_get_node (vm, node->next_nodes[i])->name);
 }
 #endif
   ASSERT (vec_len (node->next_nodes) == node_runtime->n_next_nodes);

And this was the output:

 2019-09-17 12:21:18.375523: 1: vlib_next_frame_change_ownership:293: 
vlib_next_frame_change_ownership: in ip4-arp: vec_len (node->next_nodes) 3 != 2 
node_runtime-  >n_next_nodes)
 2019-09-17 12:21:18.375600: 1: vlib_next_frame_change_ownership:296: 
vlib_next_frame_change_ownership: next 0: 595 error-drop
 2019-09-17 12:21:18.375630: 1: vlib_next_frame_change_ownership:296: 
vlib_next_frame_change_ownership: next 1: 611 UnknownEthernet1-output
 2019-09-17 12:21:18.375654: 1: vlib_next_frame_change_ownership:296: 
vlib_next_frame_change_ownership: next 2: 0 null-node
 2019-09-17 12:21:18.375678: 1: 
/var/build/mb-build/openwrt-dd/build_dir/target-aarch64_cortex-a53+neon-vfpv4_glibc-2.22/vpp-19.04.2/src/vlib/main.c:300
 (vlib_next_frame_change_ownership) assertion `vec_len (node->next_nodes) == 
node_runtime->n_next_nodes' fails

The use case is that I've got an ipsec tunnel that's *just* been brought up 
(i.e., admin up). I'm immediately sending traffic on it in a worker thread 
(polling output routine) to the other end of the tunnel (and thus receiving 
from the other end which is doing the same thing). Depending on the order the 
tunnel endpoint interfaces are brought up I may or may not hit the above, but 
it happens most of the time on at least one endpoint.

In any case, is this hitting some sort of race condition with node/graph 
construction? I wonder this b/c I would think it should not happen that a 
node's next array is larger than the node's runtime count of the same, but only 
for some short period of time.

Thanks,
Chris.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

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

[Shwetha bhandari via Lists.Fd.Io]

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,
Shwetha 

On 9/17/19, 5:06 PM, "Justin Iurman"  wrote:

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 of the draft (i.e., adding support for 
IOAM namespaces). Now that the draft is mature, you should see updates soon 
(both for kernel and vpp).

AFAIK, HbH options are already up to date (maybe not all?). Only the very 
last version of the draft (version 7) introduces a change on Trace Option's 
bitfield, which causes a reordering of options (mainly for opaque snap and csum 
complement options). That's the same for my kernel implementation, which is not 
yet up to date with version 7 (will update it ASAP). Things are evolving from a 
draft point of view, which will ease interoperability tests between kernel & 
vpp (it's on the todo list).

Cheers,
Justin

- Mail original -
> De: "Davi Scofield" 
> À: shwet...@cisco.com
> Cc: "vpp-dev" 
> Envoyé: Mardi 17 Septembre 2019 02:20:34
> Objet: Re: [vpp-dev] P4 INT( Inband Network Telemetry)

> Hi, Shwetha,
> There are many changes in IETF draft [
> https://www.ietf.org/id/draft-ietf-ippm-ioam-data-07.txt. |
> https://www.ietf.org/id/draft-ietf-ippm-ioam-data-07.txt. And they also 
give a
> demo on IETF 105# Hackathons, this demo implentented the IPv6 Hop-by-hop
> options to support IOAM in Linux kernel. To see
> 
https://github.com/IETF-Hackathon/ietf105-project-presentations/blob/master/ioam-hbh-option.pdf.
> ]
> Do you have develop plan to update the VPP to the IOAM latest 
version,including
> IPV6 Hop-by-hop option?
> 
> Thanks,
> Davi
> 
> 
> 
> 
> 
> At 2019-06-06 07:58:22, "Shwetha bhandari via Lists.Fd.Io"
>  wrote:
> 
> 
> 
> 
> 
> Hi Davi,
> 
> 
> 
> We have an reference implementation of In-situ OAM (IOAM) in VPP - [
> https://docs.fd.io/vpp/18.07/ioam_plugin_doc.html |
> https://docs.fd.io/vpp/18.07/ioam_plugin_doc.html ] , that provides Inband
> network telemetry being defined at IETF - [
> https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-05 |
> https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-05 ] .
> 
> IOAM and P4 INT both are defined to provide a way to add and collect 
packet
> trace and operational state of the nodes that forward the packet.
> 
> 
> 
> Thanks,
> 
> Shwetha
> 
> 
> 
> 
> From:  on behalf of Davi Scofield 

> Date: Wednesday, June 5, 2019 at 1:43 PM
> To: Davi Scofield 
> Cc: vpp-dev 
> Subject: [vpp-dev] P4 INT( Inband Network Telemetry)
> 
> 
> 
> 
> 
> 
> 
> 
> Hello,
> 
> 
> How to implement P4 Inband Network Telemetry function in current VPP? Is 
there
> anyone want to use this feature?
> 
> 
> Thanks ！
> 
> 
> Davi


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

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

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

[Justin Iurman]

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 of the draft (i.e., adding support for IOAM 
namespaces). Now that the draft is mature, you should see updates soon (both 
for kernel and vpp).

AFAIK, HbH options are already up to date (maybe not all?). Only the very last 
version of the draft (version 7) introduces a change on Trace Option's 
bitfield, which causes a reordering of options (mainly for opaque snap and csum 
complement options). That's the same for my kernel implementation, which is not 
yet up to date with version 7 (will update it ASAP). Things are evolving from a 
draft point of view, which will ease interoperability tests between kernel & 
vpp (it's on the todo list).

Cheers,
Justin

- Mail original -
> De: "Davi Scofield" 
> À: shwet...@cisco.com
> Cc: "vpp-dev" 
> Envoyé: Mardi 17 Septembre 2019 02:20:34
> Objet: Re: [vpp-dev] P4 INT( Inband Network Telemetry)

> Hi, Shwetha,
> There are many changes in IETF draft [
> https://www.ietf.org/id/draft-ietf-ippm-ioam-data-07.txt. |
> https://www.ietf.org/id/draft-ietf-ippm-ioam-data-07.txt. And they also give a
> demo on IETF 105# Hackathons, this demo implentented the IPv6 Hop-by-hop
> options to support IOAM in Linux kernel. To see
> https://github.com/IETF-Hackathon/ietf105-project-presentations/blob/master/ioam-hbh-option.pdf.
> ]
> Do you have develop plan to update the VPP to the IOAM latest 
> version,including
> IPV6 Hop-by-hop option?
> 
> Thanks,
> Davi
> 
> 
> 
> 
> 
> At 2019-06-06 07:58:22, "Shwetha bhandari via Lists.Fd.Io"
>  wrote:
> 
> 
> 
> 
> 
> Hi Davi,
> 
> 
> 
> We have an reference implementation of In-situ OAM (IOAM) in VPP - [
> https://docs.fd.io/vpp/18.07/ioam_plugin_doc.html |
> https://docs.fd.io/vpp/18.07/ioam_plugin_doc.html ] , that provides Inband
> network telemetry being defined at IETF - [
> https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-05 |
> https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-05 ] .
> 
> IOAM and P4 INT both are defined to provide a way to add and collect packet
> trace and operational state of the nodes that forward the packet.
> 
> 
> 
> Thanks,
> 
> Shwetha
> 
> 
> 
> 
> From:  on behalf of Davi Scofield 
> Date: Wednesday, June 5, 2019 at 1:43 PM
> To: Davi Scofield 
> Cc: vpp-dev 
> Subject: [vpp-dev] P4 INT( Inband Network Telemetry)
> 
> 
> 
> 
> 
> 
> 
> 
> Hello,
> 
> 
> How to implement P4 Inband Network Telemetry function in current VPP? Is there
> anyone want to use this feature?
> 
> 
> Thanks ！
> 
> 
> Davi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

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

[Damjan Marion via Lists.Fd.Io]

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 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 are the sequences that I compiled VPP:
> 1) Build and install DPDK
> $ cd $(DPDK)
> $ sudo make install T=x86_64-native-linuxapp-gcc DESTDIR=/usr/local
> Successfully compiled and installed as intended!
> 
> 2) Modify vpp.mk to include external DPDK by using vpp_dpdk_inc_dir and other 
> parameters, and build (make build)
> $ cd $(VPP)
> $ vi build-data/platforms/vpp.mk
> $ make build
> Modification on vpp.mk has any effect, and I checked the sources but I cannot 
> find any option to use vpp_dpdk_inc_dir. -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13998): https://lists.fd.io/g/vpp-dev/message/13998
> Mute This Topic: https://lists.fd.io/mt/34173994/675642
> Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480514
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#14001): https://lists.fd.io/g/vpp-dev/message/14001
Mute This Topic: https://lists.fd.io/mt/34173994/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Sun, Chenmin]

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: vpp-dev@lists.fd.io
Subject: 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 increased DPDK’s stack usage.
I have pushed a patch to gerrit that fixes this bug: 
https://gerrit.fd.io/r/c/vpp/+/22074 .

Best,
Aloÿs


On 16 Sep 2019, at 08:12, Sun, Chenmin 
mailto:chenmin@intel.com>> wrote:

Hi,

I've bisected and found this issue is imported by DPDK commit:

commit 1f4d55be438b428bed74f2e3dc49cfd6efc3e6fd
Author: Maxime Coquelin 
mailto:maxime.coque...@redhat.com>>
Date:   Wed May 29 15:04:20 2019 +0200

eal/x86: force inlining of all memcpy and mov helpers

Some helpers in the header file are forced inlined other are
only inlined, this patch forces inline for all.

It will avoid it to be embedded as functions when called multiple
times in the same object file. For example, when we added packed
ring support in vhost-user library, rte_memcpy_generic got no
more inlined.

Signed-off-by: Maxime Coquelin 
mailto:maxime.coque...@redhat.com>>
Acked-by: Bruce Richardson 
mailto:bruce.richard...@intel.com>>

The segment fault disappeared after I reverted this commit.
I also tried with testpmd, which is a DPDK app integrated in DPDK code, and 
didn't see this issue.

That DPDK commit just changed the function declaration from inlie to 
__rte_always_inline, all seems ok but why brings such a strange issue to 
VPP(debug mode only).

-
Best Regards,
Sun, Chenmin

From: Yang, Zhiyong
Sent: Monday, September 16, 2019 2:08 PM
To: Sun, Chenmin mailto:chenmin@intel.com>>
Subject: FW: [vpp-dev] Issue with DPDK 19.08 / i40e driver



From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Damjan Marion 
via Lists.Fd.Io
Sent: Thursday, September 12, 2019 9:00 PM
To: Aloys Augustin (aloaugus) mailto:aloau...@cisco.com>>
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Issue with DPDK 19.08 / i40e driver


Florin hit the same issue few weeks ago, don't use debug version of DPDK and it 
will work OK.
it is unlikely vpp issue, as it happens only when dpdk is compiled with -g0.
It looks like stack corruption in dpdk. If somebody have cycles, probably 
bisecting the dpdk
between last two releases will give some clue what is wrong.

On 12 Sep 2019, at 13:55, Aloys Augustin (aloaugus) via Lists.Fd.Io 
mailto:aloaugus=cisco@lists.fd.io>> wrote:

Hi Damjan,

I encountered the same issue on a different host with the same hardware, here 
is a stack trace:

DBGvpp# sh int
  Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
Counter  Count
FortyGigabitEthernet5e/0/01 down 9000/0/0/0
local00 down  0/0/0/0
DBGvpp# set int state FortyGigabitEthernet5e/0/0 up

Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x7fffb07b9f07 in i40e_asq_send_command (hw=0x7fc1fff9d340, 
desc=0x7fffb9880cc0, buff=0x7fc2002c3b80, buff_size=16, cmd_details=0x0)
at 
/home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/base/i40e_adminq.c:933
933 wr32(hw, hw->aq.asq.tail, 
hw->aq.asq.next_to_use);
(gdb) bt
#0  0x7fffb07b9f07 in i40e_asq_send_command (hw=0x7fc1fff9d340, 
desc=0x7fffb9880cc0, buff=0x7fc2002c3b80, buff_size=16, cmd_details=0x0)
at 
/home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/base/i40e_adminq.c:933
#1  0x7fffb0812e1c in i40e_aq_remove_macvlan (hw=0x7fc1fff9d340, seid=390, 
mv_list=0x7fc2002c3b80, count=1, cmd_details=0x0)
at 
/home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/base/i40e_common.c:3121
#2  0x7fffb0992a10 in i40e_remove_macvlan_filters (vsi=0x7fc1fff1aac0, 
filter=0x7fc1fff1c280, total=1) at 
/home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/i40e_ethdev.c:6881
#3  0x7fffb09bd4b8 in i40e_vsi_delete_mac (vsi=0x7fc1fff1aac0, 
addr=0x7fffb98856c0) at 
/home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/i40e_ethdev.c:7319
#4  0x7fffb0a2172b in i40e_set_default_mac_addr (dev=0x7fffb3069d00 
, mac_addr=0x7fc1fff1a500) at 
/home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/i40e_ethdev.c:11962
#5  0x7fffaffb3491 in rte_eth_dev_mac_restore (dev=0x7fffb3069d00 
, dev_in

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

[Aloys Augustin (aloaugus) via Lists.Fd.Io]

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 increased DPDK’s stack usage.
I have pushed a patch to gerrit that fixes this bug: 
https://gerrit.fd.io/r/c/vpp/+/22074  .

Best,
Aloÿs

> On 16 Sep 2019, at 08:12, Sun, Chenmin  wrote:
> 
> Hi, <>
>  
> I've bisected and found this issue is imported by DPDK commit:
>  
> commit 1f4d55be438b428bed74f2e3dc49cfd6efc3e6fd
> Author: Maxime Coquelin  >
> Date:   Wed May 29 15:04:20 2019 +0200
>  
> eal/x86: force inlining of all memcpy and mov helpers
>  
> Some helpers in the header file are forced inlined other are
> only inlined, this patch forces inline for all.
>  
> It will avoid it to be embedded as functions when called multiple
> times in the same object file. For example, when we added packed
> ring support in vhost-user library, rte_memcpy_generic got no
> more inlined.
>  
> Signed-off-by: Maxime Coquelin  >
> Acked-by: Bruce Richardson  >
>  
> The segment fault disappeared after I reverted this commit.
> I also tried with testpmd, which is a DPDK app integrated in DPDK code, and 
> didn't see this issue.
>  
> That DPDK commit just changed the function declaration from inlie to 
> __rte_always_inline, all seems ok but why brings such a strange issue to 
> VPP(debug mode only).
>  
> -
> Best Regards,
> Sun, Chenmin
>  
> From: Yang, Zhiyong 
> Sent: Monday, September 16, 2019 2:08 PM
> To: Sun, Chenmin 
> Subject: FW: [vpp-dev] Issue with DPDK 19.08 / i40e driver
>  
>  
>  
>  <>From: vpp-dev@lists.fd.io  
> mailto:vpp-dev@lists.fd.io>> On Behalf Of Damjan Marion 
> via Lists.Fd.Io
> Sent: Thursday, September 12, 2019 9:00 PM
> To: Aloys Augustin (aloaugus) mailto:aloau...@cisco.com>>
> Cc: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] Issue with DPDK 19.08 / i40e driver
>  
>  
> Florin hit the same issue few weeks ago, don't use debug version of DPDK and 
> it will work OK.
> it is unlikely vpp issue, as it happens only when dpdk is compiled with -g0.
> It looks like stack corruption in dpdk. If somebody have cycles, probably 
> bisecting the dpdk
> between last two releases will give some clue what is wrong.
>  
> 
> On 12 Sep 2019, at 13:55, Aloys Augustin (aloaugus) via Lists.Fd.Io 
> mailto:aloaugus=cisco@lists.fd.io>> 
> wrote:
>  
> Hi Damjan,
>  
> I encountered the same issue on a different host with the same hardware, here 
> is a stack trace:
>  
> DBGvpp# sh int
>   Name   IdxState  MTU (L3/IP4/IP6/MPLS) 
> Counter  Count
> FortyGigabitEthernet5e/0/01 down 9000/0/0/0
> local00 down  0/0/0/0
> DBGvpp# set int state FortyGigabitEthernet5e/0/0 up
>  
> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
> 0x7fffb07b9f07 in i40e_asq_send_command (hw=0x7fc1fff9d340, 
> desc=0x7fffb9880cc0, buff=0x7fc2002c3b80, buff_size=16, cmd_details=0x0)
> at 
> /home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/base/i40e_adminq.c:933
> 933 wr32(hw, hw->aq.asq.tail, 
> hw->aq.asq.next_to_use);
> (gdb) bt
> #0  0x7fffb07b9f07 in i40e_asq_send_command (hw=0x7fc1fff9d340, 
> desc=0x7fffb9880cc0, buff=0x7fc2002c3b80, buff_size=16, cmd_details=0x0)
> at 
> /home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/base/i40e_adminq.c:933
> #1  0x7fffb0812e1c in i40e_aq_remove_macvlan (hw=0x7fc1fff9d340, 
> seid=390, mv_list=0x7fc2002c3b80, count=1, cmd_details=0x0)
> at 
> /home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/base/i40e_common.c:3121
> #2  0x7fffb0992a10 in i40e_remove_macvlan_filters (vsi=0x7fc1fff1aac0, 
> filter=0x7fc1fff1c280, total=1) at 
> /home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/i40e_ethdev.c:6881
> #3  0x7fffb09bd4b8 in i40e_vsi_delete_mac (vsi=0x7fc1fff1aac0, 
> addr=0x7fffb98856c0) at 
> /home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/i40e_ethdev.c:7319
> #4  0x7fffb0a2172b in i40e_set_default_mac_addr (dev=0x7fffb3069d00 
> , mac_addr=0x7fc1fff1a500) at 
> /home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/drivers/net/i40e/i40e_ethdev.c:11962
> #5  0x7fffaffb3491 in rte_eth_dev_mac_restore (dev=0x7fffb3069d00 
> , dev_info=0x7fffb9885770) at 
> /home/aloaugus/vpp/build-root/build-vpp_debug-native/external/dpdk-19.08/lib/librte_eth

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

[Jaemin Park]

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 are the sequences that I compiled VPP:
1) Build and install DPDK
$ cd $(DPDK)
$ sudo make install T=x86_64-native-linuxapp-gcc DESTDIR=/usr/local
Successfully compiled and installed as intended!

2) Modify vpp.mk to include external DPDK by using vpp_dpdk_inc_dir and other 
parameters, and build ( make build )
$ cd $(VPP)
$ vi build-data/platforms/vpp.mk
$ make build
Modification on vpp.mk has any effect, and I checked the sources but I cannot 
find any option to use vpp_dpdk_inc_dir.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13998): https://lists.fd.io/g/vpp-dev/message/13998
Mute This Topic: https://lists.fd.io/mt/34173994/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] gprof?

[Benoit Ganne (bganne) via Lists.Fd.Io]

>> 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) should be dwarf. lbr should be the way
>> to go on Intel Haswell and later.
> FWIW, this is being run on the Macchiatobin platform (i.e., aarch64
> cortex-A72). :)

My bad. Not sure what is going-on but it looks like gcc also omit fp by default 
on aarch64: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
Did you had a chance to try dwarf instead of fp?

Ben
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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