Re: [vpp-dev] [infra-steering] Something wrong with the CentOS repo?

[Marco Varlese]

I tried a 'recheck' and the error is still there so likely is really broken?

On Fri, 2018-02-16 at 13:34 +0100, Marco Varlese wrote:
> Hi,
> 
> I am not sure whether this was just an hiccup or something "more serious" so
> just letting you know...
> 
> Please, see the logs below which happened on the build for CentOS:
> 
> 09:58:32 REPO_URL: https://nexus.fd.io/content/repositories/fd.io.master.cento
> s7
> 09:58:33 Loaded plugins: fastestmirror, langpacks
> 09:59:06 https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodat
> a/
> repomd.xml: [Errno 12] Timeout on https://nexus.fd.io/content/repositories/fd.
> io
> .master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000
> bytes/sec transferred the last 30 seconds')
> 09:59:06 Trying other mirror.
> 
> [... MANY MORE LOGS SIMILAR TO THE ABOVE ]
> 
> 10:03:43 https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodat
> a/
> repomd.xml: [Errno 12] Timeout on https://nexus.fd.io/content/repositories/fd.
> io
> .master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000
> bytes/sec transferred the last 30 seconds')
> 10:03:43 Trying other mirror.
> 10:03:43 
> 10:03:43 
> 10:03:43  One of the configured repositories failed (fd.io master branch
> latest
> merge),
> 10:03:43  and yum doesn't have enough cached data to continue. At this point
> the
> only
> 10:03:43  safe thing yum can do is fail. There are a few ways to work "fix"
> this:
> [...]
> 10:03:43 failure: repodata/repomd.xml from fdio-master: [Errno 256] No more
> mirrors to try.
> 
> Full logs at https://jenkins.fd.io/job/vpp-verify-master-centos7/9475/console
> 
> 
> Cheers,
-- 
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#8239): https://lists.fd.io/g/vpp-dev/message/8239
View All Messages In Topic (1): https://lists.fd.io/g/vpp-dev/topic/11861050
Mute This Topic: https://lists.fd.io/mt/11861050/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Something wrong with the CentOS repo?

[Marco Varlese]

Hi,

I am not sure whether this was just an hiccup or something "more serious" so
just letting you know...

Please, see the logs below which happened on the build for CentOS:

09:58:32 REPO_URL: https://nexus.fd.io/content/repositories/fd.io.master.centos7
09:58:33 Loaded plugins: fastestmirror, langpacks
09:59:06 https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/
repomd.xml: [Errno 12] Timeout on https://nexus.fd.io/content/repositories/fd.io
.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000
bytes/sec transferred the last 30 seconds')
09:59:06 Trying other mirror.

[... MANY MORE LOGS SIMILAR TO THE ABOVE ]

10:03:43 https://nexus.fd.io/content/repositories/fd.io.master.centos7/repodata/
repomd.xml: [Errno 12] Timeout on https://nexus.fd.io/content/repositories/fd.io
.master.centos7/repodata/repomd.xml: (28, 'Operation too slow. Less than 1000
bytes/sec transferred the last 30 seconds')
10:03:43 Trying other mirror.
10:03:43 
10:03:43 
10:03:43  One of the configured repositories failed (fd.io master branch latest
merge),
10:03:43  and yum doesn't have enough cached data to continue. At this point the
only
10:03:43  safe thing yum can do is fail. There are a few ways to work "fix"
this:
[...]
10:03:43 failure: repodata/repomd.xml from fdio-master: [Errno 256] No more
mirrors to try.

Full logs at https://jenkins.fd.io/job/vpp-verify-master-centos7/9475/console


Cheers,
-- 
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#8237): https://lists.fd.io/g/vpp-dev/message/8237
View All Messages In Topic (1): https://lists.fd.io/g/vpp-dev/topic/11789871
Mute This Topic: https://lists.fd.io/mt/11789871/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Congrats to Marco Varlese on his election as a vpp project committer

[Marco Varlese]

Thank you Dave, the whole group of committers and the TSC for giving me this
opportunity!
Look forward to great developments in VPP!!!

Cheers,Marco
On Thu, 2018-02-08 at 23:24 +, Edward Warnicke wrote:
> Woot!
> Ed
> On Thu, Feb 8, 2018 at 8:57 AM Dave Wallace  wrote:
> >   
> > 
> >   
> >   
> > Congrats Marco!
> > 
> >   -daw-
> > 
> > 
> > 
> > 
> > On 2/8/2018 11:23 AM, Dave Barach
> >   (dbarach) wrote:
> > 
> > 
> > 
> > >   
> > >   
> > >   
> > >   
> > > It gives me great pleasure to announce Marco’s
> > > election as a vpp project committer, confirmed a few minutes
> > > ago by the fd.io vpp TSC.
> > >
> > > Vanessa V. will take care of [+2 button]
> > > mechanics shortly.
> > > 
> > >
> > > Thanks much to Marco for his interest in the vpp
> > > project!
> > >
> > > Dave
> > >   
> > >   
> > > 
> > >   
> > >   
> > > 
> > >   ___
> > > vpp-dev mailing list
> > > vpp-dev@lists.fd.io
> > > https://lists.fd.io/mailman/listinfo/vpp-dev
> > > 
> > 
> > 
> > 
> >   
> > 
> > 
> > ___
> > 
> > vpp-dev mailing list
> > 
> > vpp-dev@lists.fd.io
> > 
> > https://lists.fd.io/mailman/listinfo/vpp-dev
> 
> 
> 
-- 
Marco V


SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

[vpp-dev] SCTP coverity-scan warnings addressed

[Marco Varlese]

Hi Chris,

Just to update you that I took care of the action item which came up during the
VPP project-meeting on Tuesday.

The patch https://gerrit.fd.io/r/#/c/10433/ addressing the warnings (8) re SCTP
was merged.


Cheers,
-- 
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Supporting vpp releases besides N and N-1

[Marco Varlese]

On Fri, 2018-01-26 at 19:40 +, Ed Warnicke wrote:
> I think you've hit on the right metric: retire those streams which are no
> longer supported.
+1


What do others think?

Ed

On Fri, Jan 26, 2018 at 3:53 PM Ed Kern (ejk)  wrote:


Id like to clean up jenkins ‘stream’ in the vpp section removing unsupported 
releases.

Note: Its more than just cosmetically ugly problem.


I could go into more detail but it comes down to “If they are not supported, 
why have them included in the build infra?”


This would mean the removal from the stream of:

1707

1704

1701

1609

1606


Anyone want to stand up and represent why these should remain?


Ed

___

vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
-- 
Marco V


SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP 18.01 Release artifacts are now available on nexus.fd.io

[Marco Varlese]

Great news! Congrats everybody!!!
On Thu, 2018-01-25 at 00:23 -0500, Dave Wallace wrote:
> 
> Folks,
> 
>   
> 
>   The VPP 18.01 Release artifacts are now available on nexus.fd.io
> 
>   
> 
>   The ubuntu.xenial and centos packages can be installed following
>   the recipe on the wiki:
>   https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages
> 
>   
> 
>   Thank you to all of the VPP community who have contributed to the
>   18.01 VPP Release.
> 
>   
> 
>   
> 
>   Elvis has left the building!
> 
>   -daw-
> 
>   
> 
> 
>   
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
-- 
Marco V


SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Build triggering on a simple commit message update?

[Marco Varlese]

Hi Ed,
On Thu, 2018-01-25 at 00:28 +, Ed Kern (ejk) wrote:
> hey marco,
> 
> 
> 
> 
> What your looking for (imo) is not a gerrit change. Its a jenkins side change
> 
> 
> 
> 
> 
>  https://gerrit.fd.io/r/10237
Thank you for showing the path; I am not very familiar with Jenkins, etc. so
this example is very much appreciated!
> 
> 
> 
> Note: I also included not running on trivial rebase which may freak some
> people out.
Yeah, possibly that should be avoided... 
> 
> 
> 
> You cant just gerrit-trigger-patch-submitted because the way they roll
> everything up and up and up it
> 
> would change behavior of all projects (outside of vpp) using that global
> trigger.
Understood.
> 
> 
> 
> I have no plans on advancing this patch..only pointing out one way to do it.
What are other people's sentiment about the current situation and the proposed
change of direction?
> 
> 
> 
> Ed
Cheers,Marco
> 
> 
> 
> > On Jan 24, 2018, at 4:13 AM, Marco Varlese <mvarl...@suse.de> wrote:
> > 
> > 
> > 
> > All,
> > 
> > 
> > 
> > I noticed that when a patch is updated solely for the commit message (and
> > pushed
> > 
> > to gerrit), gerrit triggers a complete new build. 
> > 
> > 
> > 
> > I wonder if it is possible (on the gerrit backend) to catch that a patch has
> > 
> > been submitted with only the commit-message being updated hence skipping the
> > 
> > full verification process? 
> > 
> > 
> > 
> > I am thinking about it since we could save cycles (many) on the build-
> > machines
> > 
> > between the many processes building the code on various distros.
> > 
> > 
> > 
> > Thoughts?
> > 
> > 
> > 
> > 
> > 
> > Cheers,
> > 
> > 
> > 
> > -- 
> > 
> > Marco V
> > 
> > 
> > 
> > SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
> > 
> > HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
> > 
> > ___
> > 
> > vpp-dev mailing list
> > 
> > vpp-dev@lists.fd.io
> > 
> > https://lists.fd.io/mailman/listinfo/vpp-dev
> > 
> 
> 
> 
> 
> 
> 
> 
-- 
Marco V


SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Build triggering on a simple commit message update?

[Marco Varlese]

All,

I noticed that when a patch is updated solely for the commit message (and pushed
to gerrit), gerrit triggers a complete new build. 

I wonder if it is possible (on the gerrit backend) to catch that a patch has
been submitted with only the commit-message being updated hence skipping the
full verification process? 

I am thinking about it since we could save cycles (many) on the build-machines
between the many processes building the code on various distros.

Thoughts?


Cheers,

-- 
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] openSUSE build fails

[Marco Varlese]

We (at SUSE) are currently pushing an update to 2.2.11 for openSUSE in our
repositories. Once that's confirmed to be upstream, I will push a new patch to
the ci-management repo to have the indent package upgraded to the latest version
and re-enable the "checkstyle".

Cheers,Marco
On Fri, 2017-12-15 at 13:51 +, Dave Barach (dbarach) wrote:
> With a bit of fiddling, I was able to fix gerrit 9440 so that indent 2.2.10
> and 2.2.11 appear to produce identical results...
>  
> 
> HTH... Dave
> 
>  
> 
> 
> 
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io]
> On Behalf Of Gabriel Ganne
> 
> Sent: Friday, December 15, 2017 8:42 AM
> 
> To: Billy McFall <bmcf...@redhat.com>; Marco Varlese <mvarl...@suse.de>
> 
> Cc: Damjan Marion (damarion) <damar...@cisco.com>; vpp-dev <vpp-...@lists.fd.i
> o>
> 
> Subject: Re: [vpp-dev] openSUSE build fails
> 
> 
>  
> 
> Hi,
>  
> If you browse the source 
> http://hg.savannah.gnu.org/hgweb/indent/
> The tag 2.2.11  is there, the source seems updated regularly.
>  
> Best regards,
>  
> 
> 
> --
> Gabriel Ganne
> 
> 
> 
> 
> 
> 
> 
> From:
> vpp-dev-boun...@lists.fd.io <vpp-dev-boun...@lists.fd.io> on behalf of Billy
> McFall <bmcf...@redhat.com>
> 
> Sent: Friday, December 15, 2017 2:26:42 PM
> 
> To: Marco Varlese
> 
> Cc: Damjan Marion (damarion); vpp-dev
> 
> Subject: Re: [vpp-dev] openSUSE build fails 
> 
>  
> 
> 
> 
> 
>  
> 
>  
> 
> On Fri, Dec 15, 2017 at 5:15 AM, Marco Varlese <mvarl...@suse.de> wrote:
> > 
> > Hi Damjan,
> > 
> > 
> >  
> > 
> > 
> > On Fri, 2017-12-15 at 09:06 +, Damjan Marion (damarion) wrote:
> > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > On 15 Dec 2017, at 08:52, Marco Varlese <mvarl...@suse.de> wrote:
> > > > 
> > > >  
> > > > 
> > > > 
> > > > Damjan,
> > > > 
> > > > 
> > > > 
> > > > On Thu, 2017-12-14 at 16:04 +, Damjan Marion (damarion) wrote:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > Folks,
> > > > > 
> > > > > 
> > > > > 
> > > > > I'm hearing from multiple people that OpenSUSE verify job is failing
> > > > > (again).
> > > > 
> > > > I haven't heard (or read) anything over the mailing list otherwise I
> > > > would have
> > > > 
> > > > looked into it.
> > > > 
> > > > Also, if you hear anything like that you can always ping me directly and
> > > > I will
> > > > 
> > > > look into it...
> > > > 
> > > > 
> > > 
> > >  
> > > 
> > > 
> > > yes, people pinging me...
> > > 
> > > 
> > > See 
> > > 
> > > 
> > > https://gerrit.fd.io/r/#/c/9440/
> > > 
> > > 
> > >  
> > > 
> > > 
> > > also:
> > > 
> > > 
> > >  
> > > 
> > > 
> > > https://gerrit.fd.io/r/#/c/9813/3/ -
> > >  abandoned but it shows that something was wrong
> > > 
> > > 
> > 
> >  
> > 
> > 
> > Ok, so just summarizing our conversation on IRC for others too.
> > 
> > 
> >  
> > 
> > 
> > That issue is connected to the different versions of INDENT (C checkstyle)
> > installed on the different distros.
> > 
> > 
> >  
> > 
> > 
> > openSUSE runs 2.2.10 whilst CentOS and Ubuntu run 2.2.11
> > 
> > 
> >  
> > 
> > 
> > What strikes me is that the upstream repo 
> > https://ftp.gnu.org/gnu/indent/ has 2.2.10 as last revision.
> > 
> > 
> > Our indent package maintainer is looking at possible other sources where
> > Indent could "live" these days and will let me know as soon as she finds
> > out.
> > 
> > 
> >  
> > 
> > 
> > @Thomas Herbert, would you know the source where the Indent package on
> > CentOS come from? Maybe that could help...
> > 
> > 
> 
>  
> 
> 
> Marco, I can't find the source. I'll look around a little more. From CentoOS
> 7.4:
> 
> 
>  
> 
> 
> $ sudo yum provides indent
> 
> 
> :
> 
> 
> 
> indent-2.2.11-13.el7.x86_6

Re: [vpp-dev] openSUSE build fails

[Marco Varlese]

Folks,

On Fri, 2017-12-15 at 11:15 +0100, Marco Varlese wrote:
[NIP]
> Ok, so just summarizing our conversation on IRC for others too.
> 
> That issue is connected to the different versions of INDENT (C checkstyle)
> installed on the different distros.
> 
> openSUSE runs 2.2.10 whilst CentOS and Ubuntu run 2.2.11

A patch has been submitted to circumvent this issue until we can have the same
version of Indent across distros...


[NIP]


SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] openSUSE build fails

[Marco Varlese]

On Fri, 2017-12-15 at 08:52 +0100, Marco Varlese wrote:
> Damjan,
> 
> On Thu, 2017-12-14 at 16:04 +, Damjan Marion (damarion) wrote:
> > Folks,
> > 
> > I'm hearing from multiple people that OpenSUSE verify job is failing
> > (again).
Would it be possible to have a list (few) of build logs which are failing (or
have failed)?
In that way I could at least see what's happening and come up with some idea...
I went through 3 pages of reviews ion gerrit (even the Verified+1 ones) and I
could find only a single review which failed (once) for openSUSE whilst there
are multiple failures for others.
Any input here would help to get to the bottom of it...
> 
> I haven't heard (or read) anything over the mailing list otherwise I would
> have
> looked into it.
> Also, if you hear anything like that you can always ping me directly and I
> will
> look into it...
> > 
> > So generally speaking i would like to question having verify jobs for
> > multiple
> > distros.
> > Is there really a value in compiling same code on different distros. Yes I
> > know gcc version can be different,
> > but that can be addressed in simpler way, if it needs to be addressed at
> > all.
> > 
> > More distros means more moving parts and bigger chance that something will
> > fail.
> 
> Well, I am not sure how to interpret this but (in theory) a build should be
> reproducible in the first place and I should not worry about problems with
> build
> outcomes. It doesn't only affect openSUSE and I raised it many times over the
> mailing-list; when you need to run "recheck" multiple times to have a build
> succeed. IMHO the issue should be addressed and not solved by putting it under
> the carpet...
> > Also it cost resources
> 
> That is a different matter and if that's the case then it should be discussed
> seriously; raising this argument now, after having had people investing their
> times in getting stuff up and running isn't really a cool thing...
> > 
> > Thoughts?
> > 
> > Damjan
> 
> /Marco
> > 
> > 
> > 
> > ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
-- 
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] openSUSE build fails

[Marco Varlese]

Dear David,
On Thu, 2017-12-14 at 10:01 -1000, David Cornejo wrote:
> I'm a newcomer to this list, so treat my opinion with suspicion...
> I think that there's a governance policy involved. I don't think that the
> committers should feel obligated to support something that is not in their
> interest. OpenSUSE verification needs a champion, and if that champion does
> not emerge than I'd think that the only rational thing to do is to drop it.

That champion would be myself and if it isn't clear to you then I can tell you
that over the past months I worked closely with people from LF to get openSUSE
up and running on FD.io Jenkins jobs. Beside that I am always keen and ready to
offert support to investigate issues with builds on openSUSE. As per my reply to
Damjan, I haven't heard anything this time and his email came out of the blue
for me this morning.
> FreeBSD, for example, has a policy of tiers (see https://www.freebsd.org/doc/e
> n_US.ISO8859-1/articles/committers-guide/archs.html) for platform support.
> Such a system allows for new platforms to get incorporated, but makes it clear
> how they relate to project and responsibilities. Things that exhibit developer
> support move up the tiers to where they are formally fully supported by the
> project. Platforms that fail to maintain developer support move down the tiers
> to their eventual demise. Perhaps a similar policy would work here.
> 
> dave c
> 
> 
> 
> On Thu, Dec 14, 2017 at 6:04 AM, Damjan Marion (damarion) 
> wrote:
> > Folks,
> > 
> > 
> > 
> > I'm hearing from multiple people that OpenSUSE verify job is failing
> > (again).
> > 
> > 
> > 
> > So generally speaking i would like to question having verify jobs for
> > multiple distros.
> > 
> > Is there really a value in compiling same code on different distros. Yes I
> > know gcc version can be different,
> > 
> > but that can be addressed in simpler way, if it needs to be addressed at
> > all.
> > 
> > 
> > 
> > More distros means more moving parts and bigger chance that something will
> > fail.
> > 
> > Also it cost resources
> > 
> > 
> > 
> > Thoughts?
> > 
> > 
> > 
> > Damjan
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ___
> > 
> > vpp-dev mailing list
> > 
> > vpp-dev@lists.fd.io
> > 
> > https://lists.fd.io/mailman/listinfo/vpp-dev
> > 
> 
> 
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
-- 
Marco V


SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] openSUSE build fails

[Marco Varlese]

Damjan,

On Thu, 2017-12-14 at 16:04 +, Damjan Marion (damarion) wrote:
> Folks,
> 
> I'm hearing from multiple people that OpenSUSE verify job is failing (again).
I haven't heard (or read) anything over the mailing list otherwise I would have
looked into it.
Also, if you hear anything like that you can always ping me directly and I will
look into it...
> 
> So generally speaking i would like to question having verify jobs for multiple
> distros.
> Is there really a value in compiling same code on different distros. Yes I
> know gcc version can be different,
> but that can be addressed in simpler way, if it needs to be addressed at all.
> 
> More distros means more moving parts and bigger chance that something will
> fail.
Well, I am not sure how to interpret this but (in theory) a build should be
reproducible in the first place and I should not worry about problems with build
outcomes. It doesn't only affect openSUSE and I raised it many times over the
mailing-list; when you need to run "recheck" multiple times to have a build
succeed. IMHO the issue should be addressed and not solved by putting it under
the carpet...
> Also it cost resources
That is a different matter and if that's the case then it should be discussed
seriously; raising this argument now, after having had people investing their
times in getting stuff up and running isn't really a cool thing...
> 
> Thoughts?
> 
> Damjan
/Marco
> 
> 
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
-- 
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] How to Wipe vpp!

[Marco Varlese]

Mostafa,
On Thu, 2017-12-14 at 11:39 +0330, Mostafa Salari wrote:
> Hi 
> I installed vpp on real hw!
Which command did you run when you built and installed VPP? On which distro?The
build process likely installed an RPM/DEB (depending on your distro) on your
system so you could simply use the distribution related tools (e.g. rpm/apt) to
uninstall the package.
> But now i want to completely uninstall it! What should i do?
> I did the following
> make wipe wipe-release bootstrap build
The "make wipe" and "make wipe-release" are taking care of cleaning up the
build...
> But it encountered error!
It'd be nice to report the error...
> Also i cannot force vpp_main process to stop!
Well... you can always stop a process on Linux: "ps aux|grep vpp"... take a look
at the pid and do a "kill -9 PID"... it won't be a "clean shutdown" but if you
need to stop it that will certainly work.
> And unfortunately source code is now removed!
You don't need the source code to stop/kill a running process.
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
-- 
Marco V


SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Jenkins jobs not starting from a "clean" state?

[Marco Varlese]

Thomas,

On Thu, 2017-11-30 at 10:24 -0500, Thomas F Herbert wrote:
> 
> 
> 
> 
> 
> 

[SNIP]

> >   
> >   Maybe "unhappy" is a little too strong :) :) :)
> >   
> > 
> >   
> >   I feel that being DPDK such an important piece in the VPP
> > infrastructure I would think it should be built during the 
> >   "VPP build process" rather than having the DPDK devel
> > packages installed beforehand. At the end of the day, we
> >   even have the whole infrastructure in place to built it and
> > link the built DPDK in VPP so why don't we use it?
> > 
> 
> My view is that ultimately with respect to distros support of
> fd.io/VPP the object is to have a dependency on an external upstream
> DPDK RPM. Therefore to be able to run VPP with external DPDK RPM is
> critical. I don't see the disadvantage of having DPDK RPM installed
> beforehand. 

Then I'd have a question to you Thomas: if that's the goal, shouldn't the jobs
you run on Jenkins (for CentOS) build VPP using the DPDK_SHARED mode?

Anway, as previously mentioned, for openSUSE I followed the steps not to install
the packaged DPDK so I think we can keep things as they are...

[SNIP]


Cheers,
Marco

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Jenkins jobs not starting from a "clean" state?

[Marco Varlese]

Dear Ed,
On Wed, 2017-11-29 at 18:57 +, Ed Kern (ejk) wrote:
> 
> 
> 
> > On Nov 29, 2017, at 3:09 AM, Marco Varlese <mvarl...@suse.de> wrote:
> > 
> > 
> > 
> > Hi Ed,
> > 
> > 
> > 
> > 
> > 
> > On Wed, 2017-11-29 at 03:24 +, Ed Kern (ejk) wrote:
> > > 
> > > 
> > > All the jobs that ive looked at vpp verify’s are still set to ‘single use
> > > slave’  So there is no re-use..
> > > 
> > > 
> > > 
> > > if the job is run by jenkins and is either ubuntu or centos it will
> > > attempt to pull and install 
> > > ubuntu:
> > > vpp-dpdk-dev
> > > vpp-dpdk-dkms
> > 
> > 
> > 
> > 
> > 
> > I suppose that's exactly my point of "not-clean-state”.
> > 
> 
> 
> 
> 
> Just to be clear…
> 
> 
> 
> 
> 
> Are you unhappy that it is doing those package installs before running the
> make verify (or build.sh in the case of opensuse)
> 
> Or just because you think those package installs are breaking the build.

Maybe "unhappy" is a little too strong :) :) :)
I feel that being DPDK such an important piece in the VPP infrastructure I would
think it should be built during the "VPP build process" rather than having the
DPDK devel packages installed beforehand. At the end of the day, weeven have the
whole infrastructure in place to built it and link the built DPDK in VPP so why
don't we use it?
As I just said, this is my view and not trying to enforce it!
> 
> 
> 
> 
> 
> > 
> > It will attempt to install but since it finds those packages already
> > installed then obviously it doesn't keep going.
> > 
> 
> 
> 
> 
> well no…well I certainly should have kept going (you trimmed the log you sent
> to not include the failure or a link to a specific
> 
> job.

Fair enough; my bad...
> 
> > 
> > I was trying to ask and understand how is it possible that on a "fresh
> > booted" VM there're already packages installed.
> > 
> 
> 
> 
> 
> Well when either the openstack or container image are ‘booted’ neither dpdk or
> vpp are installed.
> 
> 32k other prereqs and base packages but (tmk with openstack clone) not dpdk.

Sure and that's understood; I mistakenly used "fresh booted" here... 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > 
> > I suppose that what the message "Up-to-date DPDK package already installed"
> > points out, am I correct?
> > 
> 
> 
> 
> 
> again i want to be careful we are on the same page..
> 
> 
> 
> 
> 
> DPDK is not installed in the base template image.
> 
> 
> 
> 
> 
> DPDK IS now installed as a package (to ubuntu and centos):
> 
> AFTER check style
> 
> BEFORE make verify or build.sh
> 
> as part of the jenkins build scripts.

Yes, indeed. We're on the same page. 
What I was trying to propose is not to install DPDK as a package (ubuntu /
centos) but leave everything to the Makefile/Build infrastructure in VPP to do
those steps.That will also help us to strengthen the VPP build-infrastructure
and spot any regression when/if modifications are made to the various
Makefiles...
> 
> 
> 
> 
> > 
> > Similarly, the DPDK tarball is already downloaded when the 'curl' command
> > runs since the source tarball can already be found in /dpdk
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> So from the base template we go from no directory
> template base image is spun up
> git clone/fetch/etc is run 
> check style is run
> there should be no dpdk.xxx.tar.xz anywhere at this point 
> make verify or build.sh (im only speaking about verify builds )  is run
> as part of that ( i myself trip the download by doing make config in the dpdk
> directory, never bothered to track down how it is tripped ‘normally’)
> the tar.xz is pulled.
> 
> 
> 
> if you actually see an order different then this id be curious to see it.
> 
> 
> 
> 
> 
> thanks,
> 
> 
> 
> 
> 
> Ed
Cheers,Marco
> 
> 
> 
> > > 
> > > 
> > > centos:
> > > vpp-dpdk-devel
> > > 
> > > 
> > > 
> > > if running the build of opensuse or any build outside of jenkins it will
> > > attempt to build it from scratch..
> > 
> > Right, I believe that should always be the approach tho...
> > 
> > 
> > 
> > 
> > > (thats one of the issues you were seeing the other day)
> > > 
> > > 
> > > 
> > > https://gerrit.fd.io/r/#

Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

[Marco Varlese]

Dear Dave,

By the look of it is seemed to have been an hiccup with the download or
that something spurious was left on the filesystem...
===
12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master-
opensuse/dpdk/dpdk-17.08.tar.xz and retry
12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify-
master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed
12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build-
root/build-vpp-native/dpdk/.download.ok] Error 1
12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:460: recipe for target 'ebuild-build' failed
12:08:13 make[2]: *** [ebuild-build] Error 2
12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:682: recipe for target 'dpdk-build' failed
12:08:13 make[1]: *** [dpdk-build] Error 2
12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/build-root'
12:08:13 Makefile:333: recipe for target 'build-release' failed
12:08:13 make: *** [build-release] Error 2
12:08:13 Build step 'Execute shell' marked build as failure
===

Since the MD5 checksum on the DPDK tarball fails; to answer your
question, no, it has never happened to me to see this specific issue
before.

I don't think there's anything specific to the openSUSE setup and/or
scripts being executed. I'd rather feel is - as I said earlier -
something to do with an hiccup on the infrastructure side. The fact
that a 'recheck' made it passing I suppose it confirms my current
theory.

An idea: maybe, if it happens again, we might want to ask Vanessa to
see what's the status on the slave-node? Not sure if that could give us
some more insight of what's going on.


Cheers,
Marco

On Mon, 2017-11-27 at 11:04 -0500, Dave Wallace wrote:
> Marco,
> 
> Can you please take a look at the build failure encountered with http
> s://gerrit.fd.io/r/#/c/9582/ on the vpp-verify-master-opensuse
> jenkins job:
> 
> - %< -
> fd.io JJB  7:56 AM
> Patch Set 2: Verified-1
> Build Failed 
> https://jenkins.fd.io/job/vpp-verify-master-opensuse/459/ : FAILURE
> No problems were identified. If you know why this problem occurred,
> please add a suitable Cause for it. ( https://jenkins.fd.io/job/vpp-v
> erify-master-opensuse/459/ )
> Logs: https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-
> master-opensuse/459
> - %< --
> 
> From the logs, it appears that there is an issue related to building
> dpdk.  Have you seen this issue before?  If so, it this an
> infrastructure issue or something else?
> 
> Thanks,
> -daw-
>  ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

[Marco Varlese]

Dear Dave,

By the look of it is seemed to have been an hiccup with the download or
that something spurious was left on the filesystem...
===
12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master-
opensuse/dpdk/dpdk-17.08.tar.xz and retry
12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify-
master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed
12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build-
root/build-vpp-native/dpdk/.download.ok] Error 1
12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:460: recipe for target 'ebuild-build' failed
12:08:13 make[2]: *** [ebuild-build] Error 2
12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/dpdk'
12:08:13 Makefile:682: recipe for target 'dpdk-build' failed
12:08:13 make[1]: *** [dpdk-build] Error 2
12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master-
opensuse/build-root'
12:08:13 Makefile:333: recipe for target 'build-release' failed
12:08:13 make: *** [build-release] Error 2
12:08:13 Build step 'Execute shell' marked build as failure
===

Since the MD5 checksum on the DPDK tarball fails; to answer your
question, no, it has never happened to me to see this specific issue
before.

I don't think there's anything specific to the openSUSE setup and/or
scripts being executed. I'd rather feel is - as I said earlier -
something to do with an hiccup on the infrastructure side. The fact
that a 'recheck' made it passing I suppose it confirms my current
theory.

An idea: maybe, if it happens again, we might want to ask Vanessa to
see what's the status on the slave-node? Not sure if that could give us
some more insight of what's going on.


Cheers,
Marco

On Mon, 2017-11-27 at 11:04 -0500, Dave Wallace wrote:
> Marco,
> 
> Can you please take a look at the build failure encountered with http
> s://gerrit.fd.io/r/#/c/9582/ on the vpp-verify-master-opensuse
> jenkins job:
> 
> - %< -
> fd.io JJB  7:56 AM
> Patch Set 2: Verified-1
> Build Failed 
> https://jenkins.fd.io/job/vpp-verify-master-opensuse/459/ : FAILURE
> No problems were identified. If you know why this problem occurred,
> please add a suitable Cause for it. ( https://jenkins.fd.io/job/vpp-v
> erify-master-opensuse/459/ )
> Logs: https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-
> master-opensuse/459
> - %< --
> 
> From the logs, it appears that there is an issue related to building
> dpdk.  Have you seen this issue before?  If so, it this an
> infrastructure issue or something else?
> 
> Thanks,
> -daw-
>  ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

[Marco Varlese]

Hi Gabriel,
On Tue, 2017-11-28 at 10:13 +, Gabriel Ganne wrote:
> Hi Marco,
> 
> 
> 
> 
> 
> I believe 
> http://fast.dpdk.org/rel redirects to 
> http://static.dpdk.org/rel/
> 
> 
> 
> 
> 
> 
> 
> I disagree on the md5 hashs.
> 
> I have the following (NOK on 17.08, and OK on 17.11) :
> 
> 
> 
> 
> 
> 
> 
> $ wget 
> http://static.dpdk.org/rel/dpdk-17.08.tar.xz
> 
> 
> 
> $ openssl md5 dpdk-17.08.tar.xz
> # is 0641f59ea8ea98afefa7cfa2699f6241 in dpdk/Makefile
> 
> 
> 
> MD5(dpdk-17.08.tar.xz)= 537ff038915fefd0f210905fafcadb4b
> 
Ah, when I said correct, I said it according to the DPDK.org web-site page http:
//dpdk.org/rel which apperently shows an MD5 for 17.08 equal to the one we use
currently in VPP... :(
> 
> 
> 
> $ wget 
> http://static.dpdk.org/rel/dpdk-17.11.tar.xz
> 
> 
> $ openssl md5 dpdk-17.11.tar.xz
> 
> 
> MD5(dpdk-17.11.tar.xz)= 53ee9e054a8797c9e67ffa0eb5d0c701
> 
> 
> 
> 
> 
> 
> Though I agree that if the "recheck" button made the build pass, there must be
> something wrong on my side.
> 
> 
>  ... what did I miss ?
> 
> 
> 
> 
> 
> 
> 
> --
> 
> 
> Gabriel Ganne
> 
> 
> 
> 
> 
> 
> From: Marco Varlese <mvarl...@suse.de>
> 
> Sent: Tuesday, November 28, 2017 10:55:49 AM
> 
> To: Gabriel Ganne; Dave Wallace; Gonzalez Monroy, Sergio
> 
> Cc: vpp-dev@lists.fd.io
> 
> Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage
>  
> 
> 
> 
> 
> 
> Hi Gabriel,
> 
> 
> 
> On Tue, 2017-11-28 at 09:19 +, Gabriel Ganne wrote:
> > Hi,
> > 
> > 
> > 
> > I also have this issue on my machine, and I see on
> > 
> > http://static.dpdk.org/rel/ that dpdk-17.08.tar.xz  was written yesterday
> > (27-Nov-2017 13:00)
> > Wouldn't it be possible that the archive was overwritten ?
> > 
> 
> The DPDK tarball in VPP is downloaded from 
> http://fast.dpdk.org/rel 
> According to 
> http://dpdk.org/rel the MD5 used in VPP for the DPDK 17.08 release is correct.
> > 
> > 
> > 
> > In which case, the hash would need to be updated.
> > 
> > 
> > 
> 
> Right, if the tarball was a newer and different one then the MD5 hash should
> be updated in VPP for the the checksum performed...
> However, in the case described by Dave below, a simple 'recheck' which
> triggers a new build (with the same code/scripts/etc. hence the same MD5 hash)
> solved it.
> 
> 
> 
> > 
> > Also, this would probably not be seen by people who had the 
> > dpdk-install-dev 
> > package already installed.
> > 
> > 
> > 
> > 
> > 
> > Who should I ask to check this ?
> > 
> > 
> > 
> 
> I've added Sergio who might have further thoughts on this one.
> 
> 
> 
> > 
> > 
> > 
> > 
> > Best regards
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > 
> > 
> > Gabriel Ganne
> > 
> > 
> > 
> > 
> > 
> > From: vpp-dev-boun...@lists.fd.io <vpp-dev-boun...@lists.fd.io> on behalf of
> > Marco Varlese <mvarl...@suse.de>
> > 
> > Sent: Tuesday, November 28, 2017 9:19:37 AM
> > 
> > To: Dave Wallace
> > 
> > Cc: vpp-dev@lists.fd.io
> > 
> > Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage
> >  
> > 
> > 
> > Dear Dave,
> > 
> > 
> > 
> > By the look of it is seemed to have been an hiccup with the download or
> > 
> > that something spurious was left on the filesystem...
> > 
> > ===
> > 
> > 12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master-
> > 
> > opensuse/dpdk/dpdk-17.08.tar.xz and retry
> > 
> > 12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify-
> > 
> > master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed
> > 
> > 12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build-
> > 
> > root/build-vpp-native/dpdk/.download.ok] Error 1
> > 
> > 12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master-
> > 
> > opensuse/dpdk'
> > 
> > 12:08:13 Makefile:460: recipe for target 'ebuild-build' failed
> > 
> > 12:08:13 make[2]: *** [ebuild-build] Error 2
> > 
> > 12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master-
> > 
> > opensuse/dpdk'
> > 
> > 12:08:13 Makefile:682: recipe for target 'dp

Re: [vpp-dev] vpp-verify-master-opensuse build failure triage

[Marco Varlese]

Hi Gabriel,
On Tue, 2017-11-28 at 09:19 +, Gabriel Ganne wrote:
> Hi,
> 
> 
> 
> 
> 
> I also have this issue on my machine, and I see on
> 
> http://static.dpdk.org/rel/ that dpdk-17.08.tar.xz  was written yesterday (27-
> Nov-2017 13:00)
> 
> Wouldn't it be possible that the archive was overwritten ?
The DPDK tarball in VPP is downloaded from http://fast.dpdk.org/rel According to
http://dpdk.org/rel the MD5 used in VPP for the DPDK 17.08 release
is correct.
> 
> 
> 
> In which case, the hash would need to be updated.
Right, if the tarball was a newer and different one then the MD5 hash should be
updated in VPP for the the checksum performed...However, in the case described
by Dave below, a simple 'recheck' which triggers a new build (with the same
code/scripts/etc. hence the same MD5 hash) solved it.
> 
> Also, this would probably not be seen by people who had the dpdk-install-dev
> package already installed.
> 
> 
> 
> 
> 
> 
> 
> Who should I ask to check this ?
I've added Sergio who might have further thoughts on this one.
> 
> 
> 
> Best regards
> 
> 
> 
> 
> 
> 
> 
> --
> 
> 
> Gabriel Ganne
> 
> 
> 
> 
> 
> 
> From: vpp-dev-boun...@lists.fd.io <vpp-dev-boun...@lists.fd.io> on behalf of
> Marco Varlese <mvarl...@suse.de>
> 
> Sent: Tuesday, November 28, 2017 9:19:37 AM
> 
> To: Dave Wallace
> 
> Cc: vpp-dev@lists.fd.io
> 
> Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage
>  
> 
> 
> Dear Dave,
> 
> 
> 
> By the look of it is seemed to have been an hiccup with the download or
> 
> that something spurious was left on the filesystem...
> 
> ===
> 
> 12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master-
> 
> opensuse/dpdk/dpdk-17.08.tar.xz and retry
> 
> 12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify-
> 
> master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed
> 
> 12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build-
> 
> root/build-vpp-native/dpdk/.download.ok] Error 1
> 
> 12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master-
> 
> opensuse/dpdk'
> 
> 12:08:13 Makefile:460: recipe for target 'ebuild-build' failed
> 
> 12:08:13 make[2]: *** [ebuild-build] Error 2
> 
> 12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master-
> 
> opensuse/dpdk'
> 
> 12:08:13 Makefile:682: recipe for target 'dpdk-build' failed
> 
> 12:08:13 make[1]: *** [dpdk-build] Error 2
> 
> 12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master-
> 
> opensuse/build-root'
> 
> 12:08:13 Makefile:333: recipe for target 'build-release' failed
> 
> 12:08:13 make: *** [build-release] Error 2
> 
> 12:08:13 Build step 'Execute shell' marked build as failure
> 
> ===
> 
> 
> 
> Since the MD5 checksum on the DPDK tarball fails; to answer your
> 
> question, no, it has never happened to me to see this specific issue
> 
> before.
> 
> 
> 
> I don't think there's anything specific to the openSUSE setup and/or
> 
> scripts being executed. I'd rather feel is - as I said earlier -
> 
> something to do with an hiccup on the infrastructure side. The fact
> 
> that a 'recheck' made it passing I suppose it confirms my current
> 
> theory.
> 
> 
> 
> An idea: maybe, if it happens again, we might want to ask Vanessa to
> 
> see what's the status on the slave-node? Not sure if that could give us
> 
> some more insight of what's going on.
> 
> 
> 
> 
> 
> Cheers,
> 
> Marco
> 
> 
> 
> On Mon, 2017-11-27 at 11:04 -0500, Dave Wallace wrote:
> 
> > Marco,
> 
> > 
> 
> > Can you please take a look at the build failure encountered with http
> 
> > s://gerrit.fd.io/r/#/c/9582/ on the vpp-verify-master-opensuse
> 
> > jenkins job:
> 
> > 
> 
> > - %< -
> 
> > fd.io JJB  7:56 AM
> 
> > Patch Set 2: Verified-1
> 
> > Build Failed 
> 
> > https://jenkins.fd.io/job/vpp-verify-master-opensuse/459/ : FAILURE
> 
> > No problems were identified. If you know why this problem occurred,
> 
> > please add a suitable Cause for it. ( 
> https://jenkins.fd.io/job/vpp-v
> 
> > erify-master-opensuse/459/ )
> 
> > Logs: 
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-
> 
> > master-opensuse/459
> 
> > - %< --
> 
> > 
> 
> > From the logs, it appears that there is an issue related to building
> 
> > dpdk.  Have you seen this issue before?  If so, it this an
> 
> > i

Re: [vpp-dev] Can't run tests (ImportError: No module named bier)

[Marco Varlese]

On Wed, 2017-11-22 at 15:31 +, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Hi,
> 
> `make test-wipe` should help
Interesting... I ran "make wipe" before. 
May I suggest to have test-wipe run as part of the more generic wipe ???
I'll submit a patch...
> 
> Regards,
> Klement
Cheers,
Marco
> 
> > -Original Message-
> > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> > Behalf Of Marco Varlese
> > Sent: Wednesday, November 22, 2017 4:30 PM
> > To: vpp-dev <vpp-dev@lists.fd.io>
> > Subject: [vpp-dev] Can't run tests (ImportError: No module named bier)
> > 
> > Hi,
> > 
> > I just took latest master and cannot run tests anymore...
> > 
> > Adding tests from directory tree /home/mvarlese/repo/vpp/test Traceback
> > (most recent call last):
> >   File "run_tests.py", line 146, in 
> > discover_tests(d, cb)
> >   File "/home/mvarlese/repo/vpp/test/discover_tests.py", line 27, in
> > discover_tests
> > module = importlib.import_module(name)
> >   File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in
> > import_module
> > __import__(name)
> >   File "/home/mvarlese/repo/vpp/test/test_bier.py", line 17, in 
> > from scapy.contrib.bier import *
> > ImportError: No module named bier
> > Killing possible remaining process IDs:  9912 9914 No symlinks to failed
> > tests'
> > temporary directories found in /tmp/vpp-failed- unittests/.
> > make[1]: *** [Makefile:124: test] Error 1
> > make[1]: Leaving directory '/home/mvarlese/repo/vpp/test'
> > make: *** [Makefile:362: test] Error 2
> > 
> > Am I missing something? :(
> > 
> > 
> > Cheers,
> > Marco
> > 
> > ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Can't run tests (ImportError: No module named bier)

[Marco Varlese]

Hi,

I just took latest master and cannot run tests anymore...

Adding tests from directory tree /home/mvarlese/repo/vpp/test
Traceback (most recent call last):
  File "run_tests.py", line 146, in 
discover_tests(d, cb)
  File "/home/mvarlese/repo/vpp/test/discover_tests.py", line 27, in
discover_tests
module = importlib.import_module(name)
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/home/mvarlese/repo/vpp/test/test_bier.py", line 17, in 
from scapy.contrib.bier import *
ImportError: No module named bier
Killing possible remaining process IDs:  9912 9914
No symlinks to failed tests' temporary directories found in /tmp/vpp-failed-
unittests/.
make[1]: *** [Makefile:124: test] Error 1
make[1]: Leaving directory '/home/mvarlese/repo/vpp/test'
make: *** [Makefile:362: test] Error 2

Am I missing something? :(


Cheers,
Marco

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Please Call DigSafe...

[Marco Varlese]

On Fri, 2017-11-17 at 09:59 -0500, Dave Barach wrote:
> Dear Marco,
> 
> Good ideas. 
> 
> We could also consider public patches, -2ed by the submitter, with commit
> headlines of the form "RFC: add the XYZ feature." 
+1

> The only downside: each new patch set will kick off the verify jobs. I wonder
> if one could remove "fd.io JJB" quickly enough to keep that from happening.
Somehow, I cannot remove the "fd.io JJB" job at all on my patch submission... :(
> 
> Thanks... D.
Cheers,
Marco
> 
> -Original Message-
> From: Marco Varlese [mailto:mvarl...@suse.de] 
> Sent: Friday, November 17, 2017 9:49 AM
> To: Luke, Chris <chris_l...@comcast.com>; Dave Barach <d...@barachs.net>; vpp-
> d...@lists.fd.io
> Subject: Re: [vpp-dev] Please Call DigSafe...
> 
> Hi Chris / Dave,
> 
> Few thoughts inline...
> 
> On Fri, 2017-11-17 at 13:51 +, Luke, Chris wrote:
> > Hi Dave,
> > 
> > After spending a few minutes to work out that you were talking about a
> > proposed patch and not something any of us had merged (and, especially not
> > that I merged!), I see that what we need is a balance between not
> > discouraging
> > people to experiment, or submit their ideas, but to also steer people
> > towards
> > relevant leads before they get in too deep.
> > 
> > Problem is, if people make huge patches before ever talking to someone, our
> > first contact is when they submit it. The teaching moment is when the
> > reviewer
> > notices it. That is obviously too late for the first patch, but should help
> > with subsequent work.
> > 
> > This is why open source generally prefers people to keep their patches small
> > and thematic; most reviewers tire of seeing many large patches when they are
> > developed in isolation and are directionally unsound - to the point that
> > they
> > start to see the color bar in the review list and if it's yellow-or-worse,
> > and
> > not from someone they specifically associate with quality work, typically
> > those submissions end up ignored.
> 
> Maybe, a point to consider to come up with a "process" is whether the patch is
> addressing existing code (e.g. bug-fix / enhancement) or is a brand-new
> feature.
> 
> I would expect - as you stated - to see small (small to be quantified) patches
> to fix a bug in existing code and considerably bigger patches when adding in a
> new feature although - sometimes - finding a way to split code into multiple
> subsequent patches might be doable. Usually, the impact of a new feature
> should
> be considerably smaller (to existing code path executions) hence a big-fat
> patch
> might be acceptable...
> 
> We could use the DRAFT feature in "git review". That is very similar to the
> RFC
> (Request For Comments) method used in other projects. It might be a decent way
> to get early feedback and work on the design with key people...
> > 
> > I don't think we have contribution guidelines for VPP or fd.io in general
> > (apart from the style and doc guides); at least a very quick scan of the
> > wiki
> > was not fruitful. We should have somewhere to send new people (can we nudge
> > people who login to Gerrit for the first time?), and also people whose first
> > submission is unacceptable (too big, too complex, directionally unsound).
> > And
> > we as reviewers should remain vigilant and, importantly, consistent.
> 
> Maybe, we could have a process which starts with a DRAFT-type patch to give
> time
> to core reviewers to understand what's going on.
> Beside the patch size topic, another item I would consider is the
> length/quality
> of COMMENTS in the patch; it's pretty common (and not just to FD.io/VPP
> projects) to see very brief comments to patches which can make reviewers' life
> miserable (and after 2 days that patch-comment would mean nothing even to the
> author). IMHO that should be a straight -1...
> I am quite a new contributor to VPP but a process I built in my mind over the
> past few weeks is split into two sections and looks like:
> 
> == NEW FEATURE DEVELOPMENT == 
> 1) Reach out to core people (Dave / Damjan / Ed / Florin / Dave W / Chris /
> etc.) to understand feasibility of the proposed feature;
> 2) Write your patch (including unit-tests where applicable)
> 3) Fix coding style (make fixstyle)
> 4) Check your COMMENTS (do they reflect the code submitted? the longer the
> explanation the better)
> 5) Submit DRAFT patch to gerrit
> 6) Address any early comments
> 7) Go back to [2] or SUCCESS :)
> 
> == BUG-FIX ==
> 1) Write your patch
> 2) Run unit-tests locally
> 3) Wri

Re: [vpp-dev] Please Call DigSafe...

[Marco Varlese]

Hi Chris / Dave,

Few thoughts inline...

On Fri, 2017-11-17 at 13:51 +, Luke, Chris wrote:
> Hi Dave,
> 
> After spending a few minutes to work out that you were talking about a
> proposed patch and not something any of us had merged (and, especially not
> that I merged!), I see that what we need is a balance between not discouraging
> people to experiment, or submit their ideas, but to also steer people towards
> relevant leads before they get in too deep.
> 
> Problem is, if people make huge patches before ever talking to someone, our
> first contact is when they submit it. The teaching moment is when the reviewer
> notices it. That is obviously too late for the first patch, but should help
> with subsequent work.
> 
> This is why open source generally prefers people to keep their patches small
> and thematic; most reviewers tire of seeing many large patches when they are
> developed in isolation and are directionally unsound - to the point that they
> start to see the color bar in the review list and if it's yellow-or-worse, and
> not from someone they specifically associate with quality work, typically
> those submissions end up ignored.
Maybe, a point to consider to come up with a "process" is whether the patch is
addressing existing code (e.g. bug-fix / enhancement) or is a brand-new feature.

I would expect - as you stated - to see small (small to be quantified) patches
to fix a bug in existing code and considerably bigger patches when adding in a
new feature although - sometimes - finding a way to split code into multiple
subsequent patches might be doable. Usually, the impact of a new feature should
be considerably smaller (to existing code path executions) hence a big-fat patch
might be acceptable...

We could use the DRAFT feature in "git review". That is very similar to the RFC
(Request For Comments) method used in other projects. It might be a decent way
to get early feedback and work on the design with key people...
> 
> I don't think we have contribution guidelines for VPP or fd.io in general
> (apart from the style and doc guides); at least a very quick scan of the wiki
> was not fruitful. We should have somewhere to send new people (can we nudge
> people who login to Gerrit for the first time?), and also people whose first
> submission is unacceptable (too big, too complex, directionally unsound). And
> we as reviewers should remain vigilant and, importantly, consistent.
Maybe, we could have a process which starts with a DRAFT-type patch to give time
to core reviewers to understand what's going on.
Beside the patch size topic, another item I would consider is the length/quality
of COMMENTS in the patch; it's pretty common (and not just to FD.io/VPP
projects) to see very brief comments to patches which can make reviewers' life
miserable (and after 2 days that patch-comment would mean nothing even to the
author). IMHO that should be a straight -1...
I am quite a new contributor to VPP but a process I built in my mind over the
past few weeks is split into two sections and looks like:

== NEW FEATURE DEVELOPMENT == 
1) Reach out to core people (Dave / Damjan / Ed / Florin / Dave W / Chris /
etc.) to understand feasibility of the proposed feature;
2) Write your patch (including unit-tests where applicable)
3) Fix coding style (make fixstyle)
4) Check your COMMENTS (do they reflect the code submitted? the longer the
explanation the better)
5) Submit DRAFT patch to gerrit
6) Address any early comments
7) Go back to [2] or SUCCESS :)

== BUG-FIX ==
1) Write your patch
2) Run unit-tests locally
3) Write a clear explanation for your patch in the COMMENTS identifying (where
applicable) any Jira ticket pointing to the issue
4) Submit patch to gerrit
5) Address any early comments
6) Go back to [1] or SUCCESS :)
> 
> Chris.
Cheers,
Marco
> 
> 
> > -Original Message-
> > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> > Behalf Of Dave Barach
> > Sent: Friday, November 17, 2017 7:45
> > To: vpp-dev@lists.fd.io
> > Subject: [vpp-dev] Please Call DigSafe...
> > 
> > Folks,
> > 
> > At our next project meeting, I'd like to spend a few minutes talking about a
> > good-news / bad-news situation affecting the vpp project.
> > 
> > As the community has expanded, committers have begun noticing
> > unacceptable and unfixable patches in mission-critical code. Yesterday's
> > soap-opera episode involved the ip4/6 speed-paths.
> > 
> > I think we should allocate a bit of meeting time for folks to talk about
> > what
> > they're trying to develop, with an eye towards engaging with relevant area
> > experts from the start.
> > 
> > In most places in the US, folks planning to dig holes on their property are
> > required to call 811 (DigSafe): to avoid hitting buried gas lines and
> > blowing up
> > the neighborhood. It seems like we need to create something
> > similar for the vpp project.
> > 
> > Thoughts?
> > 
> > Thanks... Dave
> > 
> > 

Re: [vpp-dev] VPP with DPDK external build

[Marco Varlese]

On Tue, 2017-11-14 at 12:45 +, Shachar Beiser wrote:
>  
> 
>  
> 
> 
> 
> 
> From: Marco Varlese [mailto:mvarl...@suse.de] 
> 
> Sent: Tuesday, November 14, 2017 1:29 PM
> 
> To: Shachar Beiser <shacha...@mellanox.com>; vpp-dev@lists.fd.io
> 
> Cc: Amir Zeidner <amir...@mellanox.com>; Shahaf Shuler <shah...@mellanox.com>;
> Eyal Lavee <ela...@mellanox.com>
> 
> Subject: Re: [vpp-dev] VPP with DPDK external build
> 
> 
> 
>  
> 
> 
> It looks like you didn't build the dpdk plugin (dpdk_plugin.so) in VPP...
> 
> 
> 
>  
> 
> 
> 
> The first command you ran
> 
> 
> 
> >  root@kickseed:/home/shacharbe/vpp.dlopen# sudo
> > ./src/bin/vpp -c ${PWD}/src/vpp/conf/startup.conf
> 
>  
> is correct but the DPDK plugin is not loaded (I can't see it listed in the
> output you shared)
> 
> 
> 
> 
> 
> > load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> > load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
> > load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> > load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> > addressing for IPv6)
> > load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> > load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> > load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> > load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid
> > Deployment on IPv4 Infrastructure (RFC5969))
> > load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface
> > (experimetal))
> > load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address
> > Translation)
> > load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
> 
>  
> 
> Hence you get the error about an "unrecognized option" while parsing the
> configuration file.
> 
> 
> 
> > vlib_call_all_config_functions: unknown input `dpdk  dev :03:00.0 { num-
> > rx-queues 2 } no-multi-seg socket-mem 2048,2048 '
> 
>  
> 
> 
> 
> 
> Can you check that you have the dpdk plugin (file: dpdk_plugin.so) in the
> folder you currently use as your plugin directory? As per your output below
> 
> 
> 
> 
> > vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> 
> 
> 
> I believe it's /usr/lib/vpp_plugins
> 
>  
> 
>  
> 
> [S.B]
> 
> Yes it is in the /usr/lib/vpp_plugins , but I am using dpdk external and the
> library path is probably different ?!
Not, at all. As I told you in my previous email, I build VPP using DPDK-shared
mode too. Where the plugins are being "installed" does not depend on whether you
use shared or non-shared DPDK...
> root@kickseed:/home/shacharbe/vpp.dlopen# ls /usr/lib/vpp_plugins
> acl_plugin.so   flowprobe_plugin.so  ila_plugin.so   ixge_plugin.so 
> libsixrd_plugin.so  nat_plugin.so
>   dpdk_plugin.so  gtpu_plugin.so   ioam_plugin.so  lb_plugin.so   
> memif_plugin.so pppoe_plugin.so
>  
> 
> 
> 
> My plugins are in the directory:
> 
> /home/shacharbe/vpp.dlopen/src/plugins/.libs/dpdk_plugin.so
I am puzzled at how you got the plugins into the /usr/lib/vpp_plugins directory
if you still run VPP from within the folder where you build it.Did you manually
copy the plugins .so to the /usr/lib/vpp_plugins ? From your previous command,
you simply execute "make -j 32" and that does not do any "install of execs/libs
on the filesystem".
>  
> 
> Anyway setting in the startup.conf the plugin path resolves this issue.
Sure, adding the correct path helps but - somehow - in your previous execution
you were not "executing" either the right VPP (e.g. a vpp executable built
without DPDK support) or executing VPP with the DPDK plugin disabled (that is an
option you can specify in the startup.conf file) or - finally - pointing to a
folder without the dpdk plugin .so file otherwise the error couldn't be
explained...
>  
> 
> 
>  
> 
> 
> Cheers,
> 
> 
> Marco
> 
> 
>  
> 
> 
> On Tue, 2017-11-14 at 10:07 +, Shachar Beiser wrote:
> 
> > Hi ,
> >  
> >I have successfully build the DPDK by:
> > make T=x86_64-native-linuxapp-gcc install CPU_CFLAGS="-g
> > -fpic"
> >then I compiled successfully the vpp with the DPDK external by
> > following the procedure :
> > cd vpp/
> > sed -i '/vpp_uses_dpdk_mlx5_pmd/s/^# //g' build-data/platforms/vpp.mk
> > cd src/
> > autoreconf -fis
> > export CFLAGS="-g -DFORTIFY_SOURCE=2 -f

Re: [vpp-dev] VPP with DPDK external build

[Marco Varlese]

It looks like you didn't build the dpdk plugin (dpdk_plugin.so) in VPP...
The first command you ran
>  root@kickseed:/home/shacharbe/vpp.dlopen# sudo
> ./src/bin/vpp -c ${PWD}/src/vpp/conf/startup.conf

is correct but the DPDK plugin is not loaded (I can't see it listed in the
output you shared) 
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment
> on IPv4 Infrastructure (RFC5969))
> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface
> (experimetal))
> load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address
> Translation)
> load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)

Hence you get the error about an "unrecognized option" while parsing the
configuration file.
> vlib_call_all_config_functions: unknown input `dpdk  dev :03:00.0 { num-
> rx-queues 2 } no-multi-seg socket-mem 2048,2048 '

Can you check that you have the dpdk plugin (file: dpdk_plugin.so) in the folder
you currently use as your plugin directory? As per your output below 
> vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
I believe it's /usr/lib/vpp_plugins

Cheers,Marco
On Tue, 2017-11-14 at 10:07 +, Shachar Beiser wrote:
> Hi ,
>  
>I have successfully build the DPDK by:
> make T=x86_64-native-linuxapp-gcc install CPU_CFLAGS="-g
> -fpic"
>then I compiled successfully the vpp with the DPDK external by
> following the procedure :
> cd vpp/
> sed -i '/vpp_uses_dpdk_mlx5_pmd/s/^# //g' build-data/platforms/vpp.mk
> cd src/
> autoreconf -fis
> export CFLAGS="-g -DFORTIFY_SOURCE=2 -fstack-protector -fPIC
> -march=sandybridge -O2 -I/home/shacharbe/dpdk.org/x86_64-native-linuxapp-
> gcc/include -L/home/shacharbe/dpdk.org/x86_64-native-linuxapp-gcc/lib"
> ./configure --disable-japi
> make -j32
>  
> now I have an issue while I try to run the vpp with startup.conf .
> 
> What is the right command that I should use ?
>   
>  -Shachar Beiser
>  
> Different commands that  I have tried :
>  root@kickseed:/home/shacharbe/vpp.dlopen#
> sudo ./src/bin/vpp -c ${PWD}/src/vpp/conf/startup.conf
> vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment
> on IPv4 Infrastructure (RFC5969))
> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface
> (experimetal))
> load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address
> Translation)
> load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
> vlib_call_all_config_functions: unknown input `dpdk  dev :03:00.0 { num-
> rx-queues 2 } no-multi-seg socket-mem 2048,2048 '
> root@kickseed:/home/shacharbe/vpp.dlopen# sudo ./src/bin/vpp -c
> ${PWD}/src/vpp/conf/startup.conf plugin_path ${PWD}/plugins/.libs/
> vlib_plugin_early_init:356: plugin path
> /home/shacharbe/vpp.dlopen/plugins/.libs/
> vlib_call_all_config_functions: unknown input `-c
> /home/shacharbe/vpp.dlopen/src/vpp/conf/startup.conf'
> root@kickseed:/home/shacharbe/vpp.dlopen# sudo ./src/bin/vpp unix -c
> ${PWD}/src/vpp/conf/startup.conf
> vlib_plugin_config: unknown input '/home/shacharbe/vpp.dlopen/src...'
> root@kickseed:/home/shacharbe/vpp.dlopen# sudo ./src/bin/vpp
> vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment

Re: [vpp-dev] dpdk external

[Marco Varlese]

Hi,
On Sun, 2017-11-12 at 12:08 +, Shachar Beiser wrote:
> Hi,
> 
>  
> 
>  I followed the instructions in the previous email, but it is still not
> working. ( See the compilation issue down below)
> 
>  Could be that issue is in the DPDK compilation and not in the VPP itself
> ?
> 
>  I am compiling the DPDK as follows:
> 
>Home/Ubuntu/dpdk >sudo make install T=x86_64-native-linuxapp-gcc
> -j32.
> 
>  Is that the way you have built your DPDK ?  
Before invoking the actual make command... do this:export 
EXTRA_CFLAGS="-Wformat 
-fPIC -Wno-error=array-bounds"
>   
> 
>-Shachar Beiser.
> 
>  
> 
> make V=1 bootstrap
> 
> make V=1 build-release
> 
>  
> 
> /usr/bin/ld: /home/ubuntu/dpdk.org/x86_64-native-linuxapp-
> gcc/lib/librte_mempool_stack.a(rte_mempool_stack.o): relocation R_X86_64_32
> against `.rodata.str1.1' can not be used when making a shared object;
> recompile
>  with -fPIC
> 
> /home/ubuntu/dpdk.org/x86_64-native-linuxapp-
> gcc/lib/librte_mempool_stack.a(rte_mempool_stack.o): error adding symbols: Bad
> value
> 
> collect2: error: ld returned 1 exit status
> 
> Makefile:1613: recipe for target 'dpdk_plugin.la' failed
Cheers,Marco
>  
> 
> 
> 
> From: Marco Varlese [mailto:mvarl...@suse.de] 
> 
> Sent: Thursday, November 9, 2017 6:12 PM
> 
> To: Shachar Beiser <shacha...@mellanox.com>; vpp-dev@lists.fd.io
> 
> Cc: Amir Zeidner <amir...@mellanox.com>; Shahaf Shuler <shah...@mellanox.com>;
> Eyal Lavee <ela...@mellanox.com>
> 
> Subject: Re: [vpp-dev] dpdk external
> 
> 
>  
> 
> Dear Beiser,
> 
> 
>  
> 
> 
> I currently build (and actually create a package for SUSE distro) for VPP
> 17.10 compiling against a shared DPDK installation without any issues.
> 
> 
>  
> 
> 
> First of all, I apply the below patch:
> 
> 
> --- build-data/platforms/vpp.mk.old 2017-08-21 16:05:45.202038250 +0200
> 
> 
> +++ build-data/platforms/vpp.mk 2017-08-21 16:05:59.794798235 +0200
> 
> 
> @@ -40,10 +40,10 @@
> 
> 
>  
> 
> 
>  # DPDK configuration parameters
> 
> 
>  # vpp_uses_dpdk_mlx5_pmd = yes
> 
> 
> -# vpp_uses_external_dpdk = yes
> 
> 
> -# vpp_dpdk_inc_dir = /usr/include/dpdk
> 
> 
> -# vpp_dpdk_lib_dir = /usr/lib
> 
> 
> -# vpp_dpdk_shared_lib = yes
> 
> 
> +vpp_uses_external_dpdk = yes
> 
> 
> +vpp_dpdk_inc_dir = /usr/include/dpdk
> 
> 
> +vpp_dpdk_lib_dir = /usr/lib
> 
> 
> +vpp_dpdk_shared_lib = yes
> 
> 
>  
> 
> 
>  # load balancer plugin is not portable on 32 bit platform
> 
> 
>  ifeq ($(MACHINE),i686)
> 
> 
>  
> 
> 
> After doing that, the steps I follow are pretty straight forward:
> 
> 
> $ make V=1 bootstrap
> 
> 
> $ make V=1 build-release
> 
> 
>  
> 
> 
> Can you try the above?
> 
> 
>  
> 
> 
>  
> 
> 
> Cheers,
> 
> 
> Marco
> 
> 
>  
> 
> 
> On Thu, 2017-11-09 at 15:10 +, Shachar Beiser wrote:
> 
> > Hi ,
> >   I am trying to compile with DPDK external . it fails to compile.
> >  
> >  -Shachar Beiser
> >  
> >  
> > Both on master branch and on origin/stable/1710 the following procedure is
> > not working
> > 
> > 
> > export CFLAGS="-g -DFORTIFY_SOURCE=2 -fstack-protector -fPIC
> > -march=sandybridge -O2 -I/home/ubuntu/dpdk.org/x86_64-native-linuxapp-
> > gcc/include  -L/home/ubuntu/dpdk.org/x86_64-native-linuxapp-gcc/lib"
> > sudo autoreconf -fis
> > sudo ./configure -disable-japi
> > sudo make -j32
> >  
> > Failure
> > 
> >  
> > CC   vnet/interface_cli.lo
> > (null):48 syntax error
> > Makefile:8077: recipe for target 'vnet/geneve/geneve.api.h' failed
> > make[2]: *** [vnet/geneve/geneve.api.h] Error 1
> > make[2]: *** Waiting for unfinished jobs
> >   CC   vnet/interface_format.lo
> > (null):48 syntax error
> > Makefile:8077: recipe for target 'vnet/dns/dns.api.h' failed
> > make[2]: *** [vnet/dns/dns.api.h] Error 1
> > make[2]: Leaving directory '/home/ubuntu/vpp.bin/src'
> > Makefile:7068: recipe for target 'all-recursive' failed
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory '/home/ubuntu/vpp.bin/src'
> > Makefile:3597: recipe for target 'all' failed
> > make: *** [all] Error 2
> >  
> >  
> >  
> >  
> > ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
> 
> 
> 
> ___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] dpdk external

[Marco Varlese]

Dear Beiser,
I currently build (and actually create a package for SUSE distro) for VPP 17.10
compiling against a shared DPDK installation without any issues.
First of all, I apply the below patch:--- build-data/platforms/vpp.mk.old   
2017-08-21 16:05:45.202038250 +0200+++ build-data/platforms/vpp.mk  2017-
08-21 16:05:59.794798235 +0200@@ -40,10 +40,10 @@  # DPDK configuration
parameters # vpp_uses_dpdk_mlx5_pmd = yes-# vpp_uses_external_dpdk = yes-#
vpp_dpdk_inc_dir = /usr/include/dpdk-# vpp_dpdk_lib_dir = /usr/lib-#
vpp_dpdk_shared_lib = yes+vpp_uses_external_dpdk = yes+vpp_dpdk_inc_dir =
/usr/include/dpdk+vpp_dpdk_lib_dir = /usr/lib+vpp_dpdk_shared_lib = yes  # load
balancer plugin is not portable on 32 bit platform ifeq ($(MACHINE),i686)
After doing that, the steps I follow are pretty straight forward:$ make V=1
bootstrap$ make V=1 build-release
Can you try the above?
Cheers,Marco
On Thu, 2017-11-09 at 15:10 +, Shachar Beiser wrote:
> Hi ,
>   I am trying to compile with DPDK external . it fails to compile.
>  
>  -Shachar Beiser
> 
>  
> Both on master branch and on origin/stable/1710 the following procedure is not
> working
> --
> --
> export CFLAGS="-g -DFORTIFY_SOURCE=2 -fstack-protector -fPIC
> -march=sandybridge -O2 -I/home/ubuntu/dpdk.org/x86_64-native-linuxapp-
> gcc/include  -L/home/ubuntu/dpdk.org/x86_64-native-linuxapp-gcc/lib"
> sudo autoreconf -fis
> sudo ./configure -disable-japi
> sudo make -j32
>  
> Failure
> 
>  
> CC   vnet/interface_cli.lo
> (null):48 syntax error
> Makefile:8077: recipe for target 'vnet/geneve/geneve.api.h' failed
> make[2]: *** [vnet/geneve/geneve.api.h] Error 1
> make[2]: *** Waiting for unfinished jobs
>   CC   vnet/interface_format.lo
> (null):48 syntax error
> Makefile:8077: recipe for target 'vnet/dns/dns.api.h' failed
> make[2]: *** [vnet/dns/dns.api.h] Error 1
> make[2]: Leaving directory '/home/ubuntu/vpp.bin/src'
> Makefile:7068: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/ubuntu/vpp.bin/src'
> Makefile:3597: recipe for target 'all' failed
> make: *** [all] Error 2
>  
>  
>  
>  
> 
> 
> 
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] FD.io Notification: VPP openSUSE jobs

[Marco Varlese]

Thank you Vanessa :)

On Mon, 2017-10-30 at 16:32 -0500, Vanessa Valderrama wrote:
> 
> What:
> 
> 
> 
> The openSUSE image issues have been resolved.  The jobs
> are passing on the sandbox.  I will be enabling openSUSE for VPP
> in production tomorrow.  Please feel free to review the jobs on
> the sandbox.
> 
> https://jenkins.fd.io/sandbox/
> 
> When: 2017-10-31 @ 1500 UTC (8:00am PDT)
> 
> Where: Please contact LF via IRC fdio-infra (valderrv) to
>   report issues
> 
> 
> 
> Impact:  VPP Gerrit voting could -1 due if openSUSE jobs
>   fail
> 
> 
> 
> 
> 
> 
> 
>   
> 
>   
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] gerrit 8872 centos validation failure (stable/1710)

[Marco Varlese]

Confirmed; I had exact same issue and rebasing sorted that out.

On Wed, 2017-10-18 at 14:00 +, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> I think I saw an email a few days ago that this is resolved by rebasing
> the patch.
> 
> HTH,
> Klement
> 
> Quoting Dave Barach (dbarach) (2017-10-18 15:56:53)
> >Please see [1]https://gerrit.fd.io/r/#/c/8872 and
> >[2]https://jenkins.fd.io/job/vpp-verify-1710-centos7/53. I’ve already
> >pressed the “recheck” button. The validation failure appears unrelated to
> >the patch.
> > 
> > 
> > 
> >Thanks... Dave
> > 
> > 
> > 
> >12:50:49 Wrote:
> >/w/workspace/vpp-verify-1710-centos7/dpdk/rpm/RPMS/x86_64/vpp-dpdk-devel-
> > 17.08-vpp1.x86_64.rpm
> > 
> >12:50:49 Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.cojge5
> > 
> >12:50:49 + umask 022
> > 
> >12:50:49 + cd /w/workspace/vpp-verify-1710-centos7/dpdk/rpm/BUILD
> > 
> >12:50:49 + /usr/bin/rm -rf
> >/w/workspace/vpp-verify-1710-centos7/dpdk/rpm/BUILDROOT/vpp-dpdk-17.08-
> > vpp1.x86_64
> > 
> >12:50:49 + exit 0
> > 
> >12:50:49 mv rpm/RPMS/x86_64/*.rpm .
> > 
> >12:50:49 git clean -fdx rpm
> > 
> >12:50:49 Removing rpm/BUILD/
> > 
> >12:50:49 Removing rpm/BUILDROOT/
> > 
> >12:50:49 Removing rpm/RPMS/
> > 
> >12:50:49 Removing rpm/SOURCES/
> > 
> >12:50:49 Removing rpm/SPECS/
> > 
> >12:50:49 Removing rpm/SRPMS/
> > 
> >12:50:49 Removing rpm/tmp/
> > 
> >12:50:49 make[2]: Leaving directory
> >`/w/workspace/vpp-verify-1710-centos7/dpdk'
> > 
> >12:50:49 sudo rpm -Uih vpp-dpdk-devel-17.08-vpp1.x86_64.rpm
> > 
> >12:50:49 
> > 
> >12:50:49   package vpp-dpdk-devel-17.08-vpp2.x86_64 (which is newer than
> >vpp-dpdk-devel-17.08-vpp1.x86_64) is already installed
> > 
> >12:50:49 make[1]: *** [install-rpm] Error 2
> > 
> >12:50:49 make[1]: Leaving directory
> >`/w/workspace/vpp-verify-1710-centos7/dpdk'
> > 
> >12:50:49 make: *** [dpdk-install-dev] Error 2
> > 
> >12:50:49 Build step 'Execute shell' marked build as failure
> > 
> >12:50:49 $ ssh-agent -k
> > 
> >12:50:49 unset SSH_AUTH_SOCK;
> > 
> >12:50:49 unset SSH_AGENT_PID;
> > 
> >12:50:49 echo Agent pid 9677 killed;
> > 
> >12:50:50 [ssh-agent] Stopped.
> > 
> >12:50:50 Skipped archiving because build is not successful
> > 
> >12:50:50 [PostBuildScript] - Execution post build scripts.
> > 
> > 
> > 
> >Thanks… Dave
> > 
> > 
> > 
> > References
> > 
> >Visible links
> >1. https://gerrit.fd.io/r/#/c/8872
> >2. https://jenkins.fd.io/job/vpp-verify-1710-centos7/53
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vpp-verify-master-centos7 failure -> rebase patch

[Marco Varlese]

On Wed, 2017-10-11 at 11:07 -0400, Dave Wallace wrote:
> Folks,
> 
>   
> 
>   The patch, https://gerrit.fd.io/r/#/c/8722/, in master has created
>   a new dpdk rpm version.  
> 
>   
> 
>   If your patch is failing vpp-verify-master-centos7 with the
>   following failure signature, you need to rebase your patch for it
>   to succeed:
> 
>   
> 
>   - %< -
> 
>   08:54:53  make[2]: Leaving directory
>   `/w/workspace/vpp-verify-master-centos7/dpdk'
> 
>   08:54:53  sudo rpm -Uih vpp-dpdk-devel-17.08-vpp1.x86_64.rpm
> 
>   08:54:53  
> 
>   08:54:53  package vpp-dpdk-devel-17.08-vpp2.x86_64 (which is
>   newer than vpp-dpdk-devel-17.08-vpp1.x86_64) is already installed
> 
>   - %< -
> 
>   
> 
>   Thanks,
> 
>   -daw-
> 
>   
> 
>   ps. Marco, I have already rebased https://gerrit.fd.io/r/#/c/8733/ id="-
> x-evo-selection-start-marker">
> 
> 
>   
> 
Thank you, Dave!___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Test failing

[Marco Varlese]

Klement,

I did notice it and I pointed that out in my previous email too.
Do you think that's caused by my patch?


Cheers,
Marco

On Wed, 2017-10-11 at 10:38 +, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Did you notice this issue?
> 
> 08:54:52 Removing rpm/SRPMS/
> 08:54:52 Removing rpm/tmp/
> 08:54:52 make[2]: Leaving directory
> `/w/workspace/vpp-verify-master-centos7/dpdk'
> 08:54:52 sudo rpm -Uih vpp-dpdk-devel-17.08-vpp1.x86_64.rpm
> 08:54:53 
> 08:54:53  package vpp-dpdk-devel-17.08-vpp2.x86_64 (which is newer
> than vpp-dpdk-devel-17.08-vpp1.x86_64) is already installed
> 08:54:53 make[1]: *** [install-rpm] Error 2
> 08:54:53 make[1]: Leaving directory
> `/w/workspace/vpp-verify-master-centos7/dpdk'
> 08:54:53 make: *** [dpdk-install-dev] Error 2
> 08:54:53 Build step 'Execute shell' marked build as failure
> 
> Thanks,
> Klement
> 
> Quoting Marco Varlese (2017-10-11 12:28:48)
> > Hi Jan,
> > 
> > Thanks for pointing to the correct TEST failure.
> > However, what I'd like to mention is that it's literally impossible to get a
> > build/run through for the past couple of days. 
> > I am not sure if it's just me being unlucky but none of the "-1 Verified" I
> > get
> > are due to the patch I submit... :(
> > Please, if you have 2 spare mins, take a look at this patch https://gerrit.f
> > d.io
> > /r/#/c/8733/ and see how many "recheck" I have and all failed.
> > 
> > 
> > Cheers,
> > Marco
> > 
> > On Wed, 2017-10-11 at 10:15 +, Jan Gelety -X (jgelety - PANTHEON
> > TECHNOLOGIES at Cisco) wrote:
> > > Hello Marco,
> > > 
> > > Regarding failure of vpp-csit-verify-virl-master job - the issue is not
> > > the TC
> > > mentioned by you below. "TC02: DUT reports packet flow for traffic with
> > > local
> > > destination address" is also marked as non-critical as it is expected to
> > > fail
> > > now. You can see it in the console log too:
> > > 
> > > 08:00:53 TC02: DUT reports packet flow for traffic with local destination
> > > address :: [Top] TG-DUT1-DUT2-TG. [Cfg] On DUT1 configure I... | FAIL |
> > > 08:00:53 Traffic script execution failed
> > > 08:00:53 ---
> > > 
> > > -
> > > 08:01:22 TC03: DUT reports packet flow for traffic with remote destination
> > > address :: [Top] TG-DUT1-DUT2-TG. [Cfg] On DUT1 configure ... | PASS |
> > > 08:01:22 ---
> > > 
> > > -
> > > 08:01:22 Tests.Vpp.Func.Telemetry.Eth2P-Ethip6-Ip6Base-Ip6Ipfixbase-Func
> > > ::
> > > *IPFIX ipv6 test cases*  | PASS |
> > > 08:01:22 0 critical tests, 0 passed, 0 failed
> > > 08:01:22 3 tests total, 2 passed, 1 failed
> > > 
> > > => there is no critical test failure (only critical tests can block the
> > > verification)
> > > 
> > > 
> > > The failed test is " Eth2P-Ethip6-Ip6Base-Ipolicemarkbase-Func .TC01: VPP
> > > policer 2R3C Color-aware marks packet":
> > > 
> > > 08:07:42 TC01: VPP policer 2R3C Color-aware marks packet :: [Top]
> > > TG=DUT1. 
> > > [ WARN ] Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ipolicemarkbase-Func -
> > > TC01:
> > > VPP policer 2R3C Color-aware marks packet 
> > > 08:07:42 The VPP PIDs are not equal!
> > > 08:07:42 Test Setup VPP PIDs: {'10.30.52.214': 9591, '10.30.52.215': 6792}
> > > 08:07:42 Test Teardown VPP PIDs: {'10.30.52.214': 9863, '10.30.52.215':
> > > 6792}
> > > 08:07:42 Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ipolicemarkbase-Func -
> > > TC01:
> > > VPP policer 2R3C Color-aware marks packet 
> > > 08:07:42 The VPP PIDs are not equal!
> > > 08:07:42 Test Setup VPP PIDs: {'10.30.52.214': 9591, '10.30.52.215': 6792}
> > > 08:07:42 Test Teardown VPP PIDs: {'10.30.52.214': 9863, '10.30.52.215':
> > > 6792}
> > > 08:07:42 | FAIL |
> > > 08:07:42 Teardown failed:
> > > 08:07:42 SSHTimeout: Timeout exception.
> > > 08:07:42 Current contents of stdout buffer: 
> > > 08:07:42 Current contents of stderr buffer:
> > > 
> > > It seems that there was VPP 

Re: [vpp-dev] Test failing

[Marco Varlese]

Hi Jan,

Thanks for pointing to the correct TEST failure.
However, what I'd like to mention is that it's literally impossible to get a
build/run through for the past couple of days. 
I am not sure if it's just me being unlucky but none of the "-1 Verified" I get
are due to the patch I submit... :(
Please, if you have 2 spare mins, take a look at this patch https://gerrit.fd.io
/r/#/c/8733/ and see how many "recheck" I have and all failed.


Cheers,
Marco

On Wed, 2017-10-11 at 10:15 +, Jan Gelety -X (jgelety - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Hello Marco,
> 
> Regarding failure of vpp-csit-verify-virl-master job - the issue is not the TC
> mentioned by you below. "TC02: DUT reports packet flow for traffic with local
> destination address" is also marked as non-critical as it is expected to fail
> now. You can see it in the console log too:
> 
> 08:00:53 TC02: DUT reports packet flow for traffic with local destination
> address :: [Top] TG-DUT1-DUT2-TG. [Cfg] On DUT1 configure I... | FAIL |
> 08:00:53 Traffic script execution failed
> 08:00:53 ---
> -
> 08:01:22 TC03: DUT reports packet flow for traffic with remote destination
> address :: [Top] TG-DUT1-DUT2-TG. [Cfg] On DUT1 configure ... | PASS |
> 08:01:22 ---
> -
> 08:01:22 Tests.Vpp.Func.Telemetry.Eth2P-Ethip6-Ip6Base-Ip6Ipfixbase-Func ::
> *IPFIX ipv6 test cases*  | PASS |
> 08:01:22 0 critical tests, 0 passed, 0 failed
> 08:01:22 3 tests total, 2 passed, 1 failed
> 
> => there is no critical test failure (only critical tests can block the
> verification)
> 
> 
> The failed test is " Eth2P-Ethip6-Ip6Base-Ipolicemarkbase-Func .TC01: VPP
> policer 2R3C Color-aware marks packet":
> 
> 08:07:42 TC01: VPP policer 2R3C Color-aware marks packet :: [Top]
> TG=DUT1. 
> [ WARN ] Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ipolicemarkbase-Func - TC01:
> VPP policer 2R3C Color-aware marks packet 
> 08:07:42 The VPP PIDs are not equal!
> 08:07:42 Test Setup VPP PIDs: {'10.30.52.214': 9591, '10.30.52.215': 6792}
> 08:07:42 Test Teardown VPP PIDs: {'10.30.52.214': 9863, '10.30.52.215': 6792}
> 08:07:42 Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ipolicemarkbase-Func - TC01:
> VPP policer 2R3C Color-aware marks packet 
> 08:07:42 The VPP PIDs are not equal!
> 08:07:42 Test Setup VPP PIDs: {'10.30.52.214': 9591, '10.30.52.215': 6792}
> 08:07:42 Test Teardown VPP PIDs: {'10.30.52.214': 9863, '10.30.52.215': 6792}
> 08:07:42 | FAIL |
> 08:07:42 Teardown failed:
> 08:07:42 SSHTimeout: Timeout exception.
> 08:07:42 Current contents of stdout buffer: 
> 08:07:42 Current contents of stderr buffer:
> 
> It seems that there was VPP restart during execution of this test.
> 
> Regards,
> Jan
> 
> -Original Message-
> From: Marco Varlese [mailto:marco.varl...@suse.com] 
> Sent: Wednesday, October 11, 2017 10:49
> To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) <jgel...@cisco.co
> m>; Ed Kern (ejk) <e...@cisco.com>
> Cc: vpp-dev@lists.fd.io; csit-...@lists.fd.io
> Subject: Re: [vpp-dev] Test failing
> 
> Today I can't get a build +1 Verified.
> 
> Different sort of errors and completely random...
> 
> https://jenkins.fd.io/job/vpp-verify-master-centos7/7520/console
> 07:11:39 make[2]: Leaving directory `/w/workspace/vpp-verify-master-
> centos7/dpdk'
> 07:11:39 sudo rpm -Uih vpp-dpdk-devel-17.08-vpp1.x86_64.rpm
> 07:11:39 
> 07:11:39  package vpp-dpdk-devel-17.08-vpp2.x86_64 (which is newer than
> vpp-dpdk-devel-17.08-vpp1.x86_64) is already installed
> 07:11:39 make[1]: *** [install-rpm] Error 2
> 07:11:39 make[1]: Leaving directory `/w/workspace/vpp-verify-master-
> centos7/dpdk'
> 07:11:39 make: *** [dpdk-install-dev] Error 2
> 07:11:39 Build step 'Execute shell' marked build as failure
> 
> https://jenkins.fd.io/job/vpp-csit-verify-virl-master/7533/console
> 08:29:44 08:00:53 TC02: DUT reports packet flow for traffic with local
> destination address :: [Top] TG-DUT1-DUT2-TG. [Cfg] On DUT1 configure I... |
> FAIL |
> 08:29:44 08:00:53 Traffic script execution failed
> 08:29:44
> ==
> ==
> 08:29:44 Final result of all test
> loops:
>   
>| FAIL |
> 08:29:44 1 critical t

Re: [vpp-dev] Test failing

[Marco Varlese]

Today I can't get a build +1 Verified.

Different sort of errors and completely random...

https://jenkins.fd.io/job/vpp-verify-master-centos7/7520/console
07:11:39 make[2]: Leaving directory `/w/workspace/vpp-verify-master-
centos7/dpdk'
07:11:39 sudo rpm -Uih vpp-dpdk-devel-17.08-vpp1.x86_64.rpm
07:11:39 
07:11:39package vpp-dpdk-devel-17.08-vpp2.x86_64 (which is newer than
vpp-dpdk-devel-17.08-vpp1.x86_64) is already installed
07:11:39 make[1]: *** [install-rpm] Error 2
07:11:39 make[1]: Leaving directory `/w/workspace/vpp-verify-master-
centos7/dpdk'
07:11:39 make: *** [dpdk-install-dev] Error 2
07:11:39 Build step 'Execute shell' marked build as failure

https://jenkins.fd.io/job/vpp-csit-verify-virl-master/7533/console
08:29:44 08:00:53 TC02: DUT reports packet flow for traffic with local
destination address :: [Top] TG-DUT1-DUT2-TG. [Cfg] On DUT1 configure I... |
FAIL |
08:29:44 08:00:53 Traffic script execution failed
08:29:44

08:29:44 Final result of all test
loops:  
   | FAIL |
08:29:44 1 critical test has failed.
08:29:44



- Marco

On Mon, 2017-10-09 at 07:26 +, Jan Gelety -X (jgelety - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Hello Marco,
> 
> I had a look on the test case log (https://jenkins.fd.io/job/vpp-csit-verify-v
> irl-master/7480/robot/report/log.html) - it's always the best action you can
> do to check what test case really caused the failure as there are some tests
> expected to fail because of non-fixed issues in VPP - and failed test is
> 
> TEST TC01: Route IPv4 packet through LISP with Bridge Domain setup.
> 
> Where no running VPP was detected (no VPP pid returned) during the test case
> setup phase.
> 
> Regards,
> Jan
> 
> -Original Message-
> From: Marco Varlese [mailto:marco.varl...@suse.com] 
> Sent: Monday, October 09, 2017 09:04
> To: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) <jgel...@cisco.co
> m>; Ed Kern (ejk) <e...@cisco.com>
> Cc: vpp-dev@lists.fd.io; csit-...@lists.fd.io
> Subject: Re: [vpp-dev] Test failing
> 
> Please, take a look at this logs:
> 
> https://jenkins.fd.io/job/vpp-csit-verify-virl-master/7480/console
> 
> After Ed and yourself mentioned it... maybe the cause of the failure is linked
> to this failure instead?
> 14:32:52 14:11:12 Tests.Vpp.Func.Ip4 Tunnels.Lisp.Eth2P-Ethip4Lisp-
> L2Bdbasemaclrn-Func :: *ip4-lispgpe-ip4 encapsulation test
> cases*  |
> FAIL |
> 14:32:52 14:11:12 1 critical test, 0 passed, 1 failed
> 14:32:52 14:11:12 1 test total, 0 passed, 1 failed
> 
> 
> Cheers,
> Marco
> 
> On Fri, 2017-10-06 at 15:49 +, Jan Gelety -X (jgelety - PANTHEON
> TECHNOLOGIES at Cisco) wrote:
> > + csit-dev
> > 
> > Hello Marco,
> > 
> > The mentioned test case is not responsible for -1 in verification as 
> > this test case is marked as non-critical. Please, provide links to 
> > affected jobs to find which TC is really failing.
> > 
> > Thanks,
> > Jan
> > 
> > -Original Message-
> > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] 
> > On Behalf Of Ed Kern (ejk)
> > Sent: Friday, October 06, 2017 17:07
> > To: Marco Varlese <marco.varl...@suse.com>
> > Cc: vpp-dev@lists.fd.io
> > Subject: Re: [vpp-dev] Test failing
> > 
> > could you throw me some example jobs?
> > 
> > thanks,
> > 
> > Ed
> > 
> > 
> > > On Oct 6, 2017, at 8:54 AM, Marco Varlese <marco.varl...@suse.com> wrote:
> > > 
> > > Hi all,
> > > 
> > > I have seen this many times these days...
> > > I wonder if it's a infra hiccup or something is really broken?
> > > 
> > > The "recheck" is becoming the norm to get a clean +1 Verified... :(
> > > 
> > > 14:32:52 14:00:32 TC04: VPP doesn't send DHCPv4 REQUEST after OFFER 
> > > with wrong
> > > XID :: Configure DHCPv4 client on interface to TG. If server   | FAIL
> > > |
> > > 14:32:52 14:00:32 Expected error 'DHCP REQUEST Rx timeout' but got 
> > > 'Traffic script execution failed'.
> > > 
> > > 
> > > Cheers,
> > > Marco
> > > ___
> > > vpp-dev mailing list
> > > vpp-dev@lists.fd.io
> > > https://lists.fd.io/mailman/listinfo/vpp-dev
> > 
> > ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
> > 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Dependency on libsubunit ? (and failing to run tests)

[Marco Varlese]

On Wed, 2017-10-11 at 08:04 +, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Is SUSE supported? If so, maybe we should add it to the verify job to
> prevent future headaches...
As of yesterday, I finally managed to clean-up the Jenkins job and have it
building fine.
For now though, that's still in the Jenkins sandbox... 
Having said that, if you take a look at the top-level Makefile, the vagrant
scripts, etc. you'll see quite some work has gone through to support
building/testing VPP on SUSE distros...
> 
> Klement
Cheers,
Marco
> 
> Quoting Marco Varlese (2017-10-11 08:49:01)
> > Well, as I said, it worked on SUSE distro...
> > 
> > I'm modifying the patch to have a OS check so to remove this dependency for
> > SUSE
> > since the "check" version we ship does not have that dependency (and we
> > don't
> > have subunit at all as previously mentioned).
> > 
> > - Marco
> > 
> > On Wed, 2017-10-11 at 06:35 +, Klement Sekera -X (ksekera - PANTHEON
> > TECHNOLOGIES at Cisco) wrote:
> > > Hi Marco,
> > > 
> > > as you can see in your review build failure, removing -lsubunit breaks
> > > existing stuff...
> > > 
> > > Thanks,
> > > Klement
> > > 
> > > Quoting Marco Varlese (2017-10-10 16:46:13)
> > > > Hi Klement,
> > > > 
> > > > Yes, once check-devel is in place, then we can remove -lsubunit from
> > > > test/ext/Makefile. Things would still work (at least on openSUSE).
> > > > 
> > > > I submitted a patch for review:
> > > > https://gerrit.fd.io/r/#/c/8736/
> > > > 
> > > > 
> > > > Cheers,
> > > > Marco
> > > > 
> > > > On Tue, 2017-10-10 at 14:03 +, Klement Sekera -X (ksekera - PANTHEON
> > > > TECHNOLOGIES at Cisco) wrote:
> > > > > Hi Marco,
> > > > > 
> > > > > this issue is already being investigated by Tom Herbert. Strange thing
> > > > > is that check requires subunit. I wonder if it works if you install
> > > > > check only. Could you try removing -lsubunit from test/ext/Makefile?
> > > > > 
> > > > > Thanks,
> > > > > Klement
> > > > > 
> > > > > Quoting Marco Varlese (2017-10-10 16:00:00)
> > > > > > Hi all,
> > > > > > 
> > > > > > As of last week I could happily run tests (e.g. make test) on my
> > > > > > distribution
> > > > > > (openSUSE).
> > > > > > 
> > > > > > When I tried again today - with latest master - I couldn't anymore:
> > > > > > 
> > > > > > make[2]: Entering directory '/home/mvarlese/repo/vpp/test/ext'
> > > > > > cc -o /home/mvarlese/repo/vpp/build-root/vapi_test/vapi_c_test
> > > > > > -std=gnu99 -g
> > > > > > -Wall -pthread -I/home/mvarlese/repo/vpp/src
> > > > > > -I/home/mvarlese/repo/vpp/build-
> > > > > > root/install-vpp-native//vpp/include
> > > > > > -I/home/mvarlese/repo/vpp/build-
> > > > > > root/vapi_test/ vapi_c_test.c -L/home/mvarlese/repo/vpp/build-
> > > > > > root/build-
> > > > > > vpp-
> > > > > > native/vpp/.libs/ -L/home/mvarlese/repo/vpp/build-root/build-vpp-
> > > > > > native/vpp/vpp-
> > > > > > api/vapi/.libs/ -lvppinfra -lvlibmemoryclient -lsvm -lpthread
> > > > > > -lcheck
> > > > > > -lsubunit
> > > > > > -lrt -lm -lvapiclient
> > > > > > /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-
> > > > > > linux/bin/ld:
> > > > > > cannot
> > > > > > find -lsubunit
> > > > > > collect2: error: ld returned 1 exit status
> > > > > > 
> > > > > > I tried to find the newly introduced dependency on libsubunit but
> > > > > > wasn't
> > > > > > successful. 
> > > > > > 
> > > > > > Can anybody shed some light?
> > > > > > Separate, we do not have that package on our distro...
> > > > > > 
> > > > > > 
> > > > > > Cheers,
> > > > > > Marco
> > > > > > 
> > > > > > ___
> > > > > > vpp-dev mailing list
> > > > > > vpp-dev@lists.fd.io
> > > > > > https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Dependency on libsubunit ? (and failing to run tests)

[Marco Varlese]

On Tue, 2017-10-10 at 12:11 -0400, Thomas F Herbert wrote:
> 
> 
> 
> 
> 
> On 10/10/2017 10:03 AM, Klement Sekera
>   -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) wrote:
> 
> 
> 
> >   Hi Marco,
> > 
> > this issue is already being investigated by Tom Herbert. Strange thing
> > is that check requires subunit. I wonder if it works if you install
> > check only. Could you try removing -lsubunit from test/ext/Makefile?
> > 
> 
> Check version 0.10 requires subunit.
> 
> The older Check version 0.9 does not.
> 
> Check version 0.10 is used in Fedora 25+
> 
> Check version 0.9 is used in Centos 7.4.
> 
> I am not sure about SUSE?
We ship version 0.11; based on your input above, I believe that's why I don't
need -lsubunit to build on openSUSE...
> I am testing a patch for cherry picking into stable/1710 now that
> straightens this out.
> 
>     I will add you (Marco) to the review.
Thanks.
> 
> >   
> > Thanks,
> > Klement
> > 
> > Quoting Marco Varlese (2017-10-10 16:00:00)
> > 
> >   
> > > Hi all,
> > > 
> > > As of last week I could happily run tests (e.g. make test) on my
> > > distribution
> > > (openSUSE).
> > > 
> > > When I tried again today - with latest master - I couldn't anymore:
> > > 
> > > make[2]: Entering directory '/home/mvarlese/repo/vpp/test/ext'
> > > cc -o /home/mvarlese/repo/vpp/build-root/vapi_test/vapi_c_test -std=gnu99
> > > -g
> > > -Wall -pthread -I/home/mvarlese/repo/vpp/src
> > > -I/home/mvarlese/repo/vpp/build-
> > > root/install-vpp-native//vpp/include -I/home/mvarlese/repo/vpp/build-
> > > root/vapi_test/ vapi_c_test.c -L/home/mvarlese/repo/vpp/build-root/build-
> > > vpp-
> > > native/vpp/.libs/ -L/home/mvarlese/repo/vpp/build-root/build-vpp-
> > > native/vpp/vpp-
> > > api/vapi/.libs/ -lvppinfra -lvlibmemoryclient -lsvm -lpthread -lcheck
> > > -lsubunit
> > > -lrt -lm -lvapiclient
> > > /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
> > > cannot
> > > find -lsubunit
> > > collect2: error: ld returned 1 exit status
> > > 
> > > I tried to find the newly introduced dependency on libsubunit but wasn't
> > > successful. 
> > > 
> > > Can anybody shed some light?
> > > Separate, we do not have that package on our distro...
> > > 
> > > 
> > > Cheers,
> > > Marco
> > > 
> > > ___
> > > vpp-dev mailing list
> > > vpp-dev@lists.fd.io
> > > https://lists.fd.io/mailman/listinfo/vpp-dev
> > > 
> > >   
> > 
> >   ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
> > 
> > 
> 
> 
> 
> -- 
> 
>   Thomas F Herbert
>   
> 
>   NFV and Fast Data Planes
>   
> 
>   Office of Technology
>   
> 
>   Red Hat
> 
>   
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Dependency on libsubunit ? (and failing to run tests)

[Marco Varlese]

Well, as I said, it worked on SUSE distro...

I'm modifying the patch to have a OS check so to remove this dependency for SUSE
since the "check" version we ship does not have that dependency (and we don't
have subunit at all as previously mentioned).

- Marco

On Wed, 2017-10-11 at 06:35 +, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Hi Marco,
> 
> as you can see in your review build failure, removing -lsubunit breaks
> existing stuff...
> 
> Thanks,
> Klement
> 
> Quoting Marco Varlese (2017-10-10 16:46:13)
> > Hi Klement,
> > 
> > Yes, once check-devel is in place, then we can remove -lsubunit from
> > test/ext/Makefile. Things would still work (at least on openSUSE).
> > 
> > I submitted a patch for review:
> > https://gerrit.fd.io/r/#/c/8736/
> > 
> > 
> > Cheers,
> > Marco
> > 
> > On Tue, 2017-10-10 at 14:03 +, Klement Sekera -X (ksekera - PANTHEON
> > TECHNOLOGIES at Cisco) wrote:
> > > Hi Marco,
> > > 
> > > this issue is already being investigated by Tom Herbert. Strange thing
> > > is that check requires subunit. I wonder if it works if you install
> > > check only. Could you try removing -lsubunit from test/ext/Makefile?
> > > 
> > > Thanks,
> > > Klement
> > > 
> > > Quoting Marco Varlese (2017-10-10 16:00:00)
> > > > Hi all,
> > > > 
> > > > As of last week I could happily run tests (e.g. make test) on my
> > > > distribution
> > > > (openSUSE).
> > > > 
> > > > When I tried again today - with latest master - I couldn't anymore:
> > > > 
> > > > make[2]: Entering directory '/home/mvarlese/repo/vpp/test/ext'
> > > > cc -o /home/mvarlese/repo/vpp/build-root/vapi_test/vapi_c_test
> > > > -std=gnu99 -g
> > > > -Wall -pthread -I/home/mvarlese/repo/vpp/src
> > > > -I/home/mvarlese/repo/vpp/build-
> > > > root/install-vpp-native//vpp/include -I/home/mvarlese/repo/vpp/build-
> > > > root/vapi_test/ vapi_c_test.c -L/home/mvarlese/repo/vpp/build-
> > > > root/build-
> > > > vpp-
> > > > native/vpp/.libs/ -L/home/mvarlese/repo/vpp/build-root/build-vpp-
> > > > native/vpp/vpp-
> > > > api/vapi/.libs/ -lvppinfra -lvlibmemoryclient -lsvm -lpthread -lcheck
> > > > -lsubunit
> > > > -lrt -lm -lvapiclient
> > > > /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
> > > > cannot
> > > > find -lsubunit
> > > > collect2: error: ld returned 1 exit status
> > > > 
> > > > I tried to find the newly introduced dependency on libsubunit but wasn't
> > > > successful. 
> > > > 
> > > > Can anybody shed some light?
> > > > Separate, we do not have that package on our distro...
> > > > 
> > > > 
> > > > Cheers,
> > > > Marco
> > > > 
> > > > ___
> > > > vpp-dev mailing list
> > > > vpp-dev@lists.fd.io
> > > > https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Dependency on libsubunit ? (and failing to run tests)

[Marco Varlese]

Hi Klement,

Yes, once check-devel is in place, then we can remove -lsubunit from
test/ext/Makefile. Things would still work (at least on openSUSE).

I submitted a patch for review:
https://gerrit.fd.io/r/#/c/8736/


Cheers,
Marco

On Tue, 2017-10-10 at 14:03 +, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Hi Marco,
> 
> this issue is already being investigated by Tom Herbert. Strange thing
> is that check requires subunit. I wonder if it works if you install
> check only. Could you try removing -lsubunit from test/ext/Makefile?
> 
> Thanks,
> Klement
> 
> Quoting Marco Varlese (2017-10-10 16:00:00)
> > Hi all,
> > 
> > As of last week I could happily run tests (e.g. make test) on my
> > distribution
> > (openSUSE).
> > 
> > When I tried again today - with latest master - I couldn't anymore:
> > 
> > make[2]: Entering directory '/home/mvarlese/repo/vpp/test/ext'
> > cc -o /home/mvarlese/repo/vpp/build-root/vapi_test/vapi_c_test -std=gnu99 -g
> > -Wall -pthread -I/home/mvarlese/repo/vpp/src
> > -I/home/mvarlese/repo/vpp/build-
> > root/install-vpp-native//vpp/include -I/home/mvarlese/repo/vpp/build-
> > root/vapi_test/ vapi_c_test.c -L/home/mvarlese/repo/vpp/build-root/build-
> > vpp-
> > native/vpp/.libs/ -L/home/mvarlese/repo/vpp/build-root/build-vpp-
> > native/vpp/vpp-
> > api/vapi/.libs/ -lvppinfra -lvlibmemoryclient -lsvm -lpthread -lcheck
> > -lsubunit
> > -lrt -lm -lvapiclient
> > /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
> > cannot
> > find -lsubunit
> > collect2: error: ld returned 1 exit status
> > 
> > I tried to find the newly introduced dependency on libsubunit but wasn't
> > successful. 
> > 
> > Can anybody shed some light?
> > Separate, we do not have that package on our distro...
> > 
> > 
> > Cheers,
> > Marco
> > 
> > ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Dependency on libsubunit ? (and failing to run tests)

[Marco Varlese]

Hi Klement,

Yes, once check-devel is in place, then we can remove -lsubunit from
test/ext/Makefile. Things would still work (at least on openSUSE).


Cheers,
Marco

On Tue, 2017-10-10 at 14:03 +, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Hi Marco,
> 
> this issue is already being investigated by Tom Herbert. Strange thing
> is that check requires subunit. I wonder if it works if you install
> check only. Could you try removing -lsubunit from test/ext/Makefile?
> 
> Thanks,
> Klement
> 
> Quoting Marco Varlese (2017-10-10 16:00:00)
> > Hi all,
> > 
> > As of last week I could happily run tests (e.g. make test) on my
> > distribution
> > (openSUSE).
> > 
> > When I tried again today - with latest master - I couldn't anymore:
> > 
> > make[2]: Entering directory '/home/mvarlese/repo/vpp/test/ext'
> > cc -o /home/mvarlese/repo/vpp/build-root/vapi_test/vapi_c_test -std=gnu99 -g
> > -Wall -pthread -I/home/mvarlese/repo/vpp/src
> > -I/home/mvarlese/repo/vpp/build-
> > root/install-vpp-native//vpp/include -I/home/mvarlese/repo/vpp/build-
> > root/vapi_test/ vapi_c_test.c -L/home/mvarlese/repo/vpp/build-root/build-
> > vpp-
> > native/vpp/.libs/ -L/home/mvarlese/repo/vpp/build-root/build-vpp-
> > native/vpp/vpp-
> > api/vapi/.libs/ -lvppinfra -lvlibmemoryclient -lsvm -lpthread -lcheck
> > -lsubunit
> > -lrt -lm -lvapiclient
> > /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld:
> > cannot
> > find -lsubunit
> > collect2: error: ld returned 1 exit status
> > 
> > I tried to find the newly introduced dependency on libsubunit but wasn't
> > successful. 
> > 
> > Can anybody shed some light?
> > Separate, we do not have that package on our distro...
> > 
> > 
> > Cheers,
> > Marco
> > 
> > ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Dependency on libsubunit ? (and failing to run tests)

[Marco Varlese]

Hi all,

As of last week I could happily run tests (e.g. make test) on my distribution
(openSUSE).

When I tried again today - with latest master - I couldn't anymore:

make[2]: Entering directory '/home/mvarlese/repo/vpp/test/ext'
cc -o /home/mvarlese/repo/vpp/build-root/vapi_test/vapi_c_test -std=gnu99 -g
-Wall -pthread -I/home/mvarlese/repo/vpp/src -I/home/mvarlese/repo/vpp/build-
root/install-vpp-native//vpp/include -I/home/mvarlese/repo/vpp/build-
root/vapi_test/ vapi_c_test.c -L/home/mvarlese/repo/vpp/build-root/build-vpp-
native/vpp/.libs/ -L/home/mvarlese/repo/vpp/build-root/build-vpp-native/vpp/vpp-
api/vapi/.libs/ -lvppinfra -lvlibmemoryclient -lsvm -lpthread -lcheck -lsubunit
-lrt -lm -lvapiclient
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot
find -lsubunit
collect2: error: ld returned 1 exit status

I tried to find the newly introduced dependency on libsubunit but wasn't
successful. 

Can anybody shed some light?
Separate, we do not have that package on our distro...


Cheers,
Marco

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Test failing

[Marco Varlese]

Please, take a look at this logs:

https://jenkins.fd.io/job/vpp-csit-verify-virl-master/7480/console

After Ed and yourself mentioned it... maybe the cause of the failure is linked
to this failure instead?
14:32:52 14:11:12 Tests.Vpp.Func.Ip4 Tunnels.Lisp.Eth2P-Ethip4Lisp-
L2Bdbasemaclrn-Func :: *ip4-lispgpe-ip4 encapsulation test cases*  |
FAIL |
14:32:52 14:11:12 1 critical test, 0 passed, 1 failed
14:32:52 14:11:12 1 test total, 0 passed, 1 failed


Cheers,
Marco

On Fri, 2017-10-06 at 15:49 +, Jan Gelety -X (jgelety - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> + csit-dev
> 
> Hello Marco,
> 
> The mentioned test case is not responsible for -1 in verification as this test
> case is marked as non-critical. Please, provide links to affected jobs to find
> which TC is really failing.
> 
> Thanks,
> Jan
> 
> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> Behalf Of Ed Kern (ejk)
> Sent: Friday, October 06, 2017 17:07
> To: Marco Varlese <marco.varl...@suse.com>
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Test failing
> 
> could you throw me some example jobs?
> 
> thanks,
> 
> Ed
> 
> 
> > On Oct 6, 2017, at 8:54 AM, Marco Varlese <marco.varl...@suse.com> wrote:
> > 
> > Hi all,
> > 
> > I have seen this many times these days...
> > I wonder if it's a infra hiccup or something is really broken?
> > 
> > The "recheck" is becoming the norm to get a clean +1 Verified... :(
> > 
> > 14:32:52 14:00:32 TC04: VPP doesn't send DHCPv4 REQUEST after OFFER with
> > wrong
> > XID :: Configure DHCPv4 client on interface to TG. If server   | FAIL |
> > 14:32:52 14:00:32 Expected error 'DHCP REQUEST Rx timeout' but got 
> > 'Traffic script execution failed'.
> > 
> > 
> > Cheers,
> > Marco
> > ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Test failing

[Marco Varlese]

Hi all,

I have seen this many times these days...
I wonder if it's a infra hiccup or something is really broken?

The "recheck" is becoming the norm to get a clean +1 Verified... :(

14:32:52 14:00:32 TC04: VPP doesn't send DHCPv4 REQUEST after OFFER with wrong
XID :: Configure DHCPv4 client on interface to TG. If server   | FAIL |
14:32:52 14:00:32 Expected error 'DHCP REQUEST Rx timeout' but got 'Traffic
script execution failed'.


Cheers,
Marco
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

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

[Marco Varlese]

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)" 
>>> <ksek...@cisco.com> 09/25/17 10:40 AM >>>
Quoting Marco Varlese (2017-09-25 10:26:50)
> Hi Klement,
> 
> >>> "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" 
> >>> <ksek...@cisco.com> 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 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
> > bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out
> > in discussion with Neale, but I didn't get a chance to test whether
> > centos works or not before it was merged.
> 
> I think it would be nice though to update other scripts too so to have one 
> single python version used across the board. 
> Currently, to build VPP on our distribution I need to require both python and 
> python3 packages since some python scripts use one rather than the other.
> Aligning python versions would make downstream consumption better I believe.
> Is this something which will/could be done?

See below.

> 
> > As for the solution, I can think of 3 options:
> > 
> > 1.) require python3 (which has been around for some ~9 years now)
> > 2.) disable generation of the C (and C++) API if python3 is not detected
> 
> I think this would be a fair compromise for distros not supporting (yet) 
> python3. However, I am not sure how this would result in the VPP CI... 
> wouldn't this break all tests running over those API?

Tests are python2.7 because scapy wasn't python3 capable when we
designed the test framework.

These are language bindings, not different API calls. Only test_vapi,
which tests that the language bindings of different types (simple
request, dump, event, etc.) work would have to be disabled.

> > 3.) convert the script to python2.7 (which is in the opposite direction of
> > where we would want to go wrt python version)
> > 
> > Thanks,
> > Klement
> 
> Cheers,
> Marco
> 
> Quoting Thomas F Herbert (2017-09-23 15:55:10)
> >All:
> > 
> >Commit 8f2a4ea, Gerrit,  [1]https://gerrit.fd.io/r/#/c/6983/ "Add new C
> >API"
> > 
> >introduces a dependency on Python 3 and breaks downstream builds for
> >Centos.
> > 
> >Unfortunately, neither RHEL nor Centos currently support Python 3.
> > 
> >Most VPPers are probably building with EPEL repo so this problem didn't
> >show up until now but actually there is no dependency on EPEL in the
> >Makefile or spec file.
> > 
> >If anybody can suggest a solution short of pushing Python 3 into the
> >downstream repos, I am open to suggestions.
> > 
> >--Tom
> > 
> >--
> >Thomas F Herbert
> >NFV and Fast Data Planes
> >Office of Technology
> >Red Hat
> > 
> > References
> > 
> >Visible links
> >1. https://gerrit.fd.io/r/#/c/6983/
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
> 
> 

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

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

[Marco Varlese]

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 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
> bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this out
> in discussion with Neale, but I didn't get a chance to test whether
> centos works or not before it was merged.

I think it would be nice though to update other scripts too so to have one 
single python version used across the board. 
Currently, to build VPP on our distribution I need to require both python and 
python3 packages since some python scripts use one rather than the other.
Aligning python versions would make downstream consumption better I believe.
Is this something which will/could be done?

> As for the solution, I can think of 3 options:
> 
> 1.) require python3 (which has been around for some ~9 years now)
> 2.) disable generation of the C (and C++) API if python3 is not detected

I think this would be a fair compromise for distros not supporting (yet) 
python3. However, I am not sure how this would result in the VPP CI... wouldn't 
this break all tests running over those API?
> 3.) convert the script to python2.7 (which is in the opposite direction of
> where we would want to go wrt python version)
> 
> Thanks,
> Klement

Cheers,
Marco

Quoting Thomas F Herbert (2017-09-23 15:55:10)
>All:
> 
>Commit 8f2a4ea, Gerrit,  [1]https://gerrit.fd.io/r/#/c/6983/ "Add new C
>API"
> 
>introduces a dependency on Python 3 and breaks downstream builds for
>Centos.
> 
>Unfortunately, neither RHEL nor Centos currently support Python 3.
> 
>Most VPPers are probably building with EPEL repo so this problem didn't
>show up until now but actually there is no dependency on EPEL in the
>Makefile or spec file.
> 
>If anybody can suggest a solution short of pushing Python 3 into the
>downstream repos, I am open to suggestions.
> 
>--Tom
> 
>--
>Thomas F Herbert
>NFV and Fast Data Planes
>Office of Technology
>Red Hat
> 
> References
> 
>Visible links
>1. https://gerrit.fd.io/r/#/c/6983/
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [discuss] FD.io Jenkins : 2017-09-21 @ 0430 UTC (9:30am PDT)

[Marco Varlese]

Vanessa,
Please, let me know if there's anything I can assist you with to get this move
further.

Cheers,Marco
On Fri, 2017-09-22 at 09:53 -0500, Vanessa Valderrama wrote:
> Unfortunately voting is configured at the job level not the OS
>   level.  We'll need work on the failures on the sandbox and ensure
>   the job is passing before we make the change in production again.
> Thanks,
> 
> Vanessa
> 
> 
> 
> On 09/22/2017 07:39 AM, Marco Varlese
>   wrote:
> 
> 
> 
> >   
> >   
> >   
> >   On Fri, 2017-09-22 at 12:36 +, Luke, Chris wrote:
> >   
> > > 
> > >   The idea was suggested so that to start
> > > with the suse jobs would not downvote the verified tag on
> > > failure, or upvote on success, so we could work on the
> > > environment without interfering with the rest of VPP.
> > > 
> > >   
> > 
> >   Thanks for the explanation. Understood and it sounds like a
> > perfect idea.
> >   
> > > 
> > >   
> > >
> > >   What I don’t know is if we decided it was
> > > possible or not.
> > > 
> > >   
> > 
> >   Ok; let's see what Vanessa says.
> >   
> > > 
> > >   
> > >    
> > >   Chris.
> > > 
> > >   
> > 
> >   Thanks,
> >   Marco
> >   
> > 
> >   
> >   
> > > 
> > >   
> > >
> > >   
> > > 
> > >   
> > > From: Marco Varlese
> > >   [mailto:marco.varl...@suse.com] 
> > > 
> > >   Sent: Friday, September 22, 2017 8:27
> > > 
> > >   To: Luke, Chris
> > >   <chris_l...@cable.comcast.com>; Vanessa
> > >   Valderrama <vvalderr...@linuxfoundation.org>;
> > >   infra-steer...@lists.fd.io; t...@lists.fd.io;
> > >   disc...@lists.fd.io; vpp-dev@lists.fd.io
> > > 
> > >   Subject: Re: [vpp-dev] [discuss] FD.io Jenkins
> > >   : 2017-09-21 @ 0430 UTC (9:30am PDT)
> > >   
> > > 
> > >  
> > > 
> > >   I think we had the issue with
> > > virtualenv before and I thought that was fixed (zypper
> > > in python-virtualenv python3-virtualenv).
> > > 
> > > 
> > >
> > > 
> > > 
> > >   Now, since you mentioned something
> > > new to me; what's the difference between voting and
> > > non-voting jobs? How are they chosen?
> > > 
> > > 
> > >
> > > 
> > > 
> > >
> > > 
> > > 
> > >   Cheers,
> > > 
> > > 
> > >   Marco
> > > 
> > > 
> > >
> > > 
> > > 
> > >   On Fri, 2017-09-22 at 12:10 +,
> > > Luke, Chris wrote:
> > > 
> > > 
> > > >   I’m sure Vanessa will correct me
> > > > where I am wrong, but I the suse build was failing on
> > > > basic things (missing virtualenv) and downvoting
> > > > otherwise good patches; After I reported this I thought
> > > > she was going to make them non-voting jobs (since it I
> > > > thought I saw somewhere this is what they ought to be),
> > > > but it seems it was removed from the trigger entirely.
> > > >
> > > >   Chris.
> > > >
> > > >   
> > > > 
> > > >   
> > > > From: vpp-dev-boun...@lists.fd.io
> > > >   

Re: [vpp-dev] [discuss] FD.io Jenkins : 2017-09-21 @ 0430 UTC (9:30am PDT)

[Marco Varlese]

On Fri, 2017-09-22 at 12:36 +, Luke, Chris wrote:
> The idea was suggested so that to start with the suse jobs would not downvote
> the verified tag on failure, or upvote on success, so we could work on the
> environment without interfering with the rest of VPP.
Thanks for the explanation. Understood and it sounds like a perfect idea.
>  
> 
> What I don’t know is if we decided it was possible or not.
Ok; let's see what Vanessa says.
>  
> 
> Chris.
Thanks,Marco
>  
> 
> 
> 
> From: Marco Varlese [mailto:marco.varl...@suse.com] 
> 
> Sent: Friday, September 22, 2017 8:27
> 
> To: Luke, Chris <chris_l...@cable.comcast.com>; Vanessa Valderrama  a...@linuxfoundation.org>; infra-steer...@lists.fd.io; t...@lists.fd.io; 
> discuss@l
> ists.fd.io; vpp-dev@lists.fd.io
> 
> Subject: Re: [vpp-dev] [discuss] FD.io Jenkins : 2017-09-21 @ 0430 UTC (9:30am
> PDT)
> 
> 
>  
> 
> I think we had the issue with virtualenv before and I thought that was fixed
> (zypper in python-virtualenv python3-virtualenv).
> 
> 
>  
> 
> 
> Now, since you mentioned something new to me; what's the difference between
> voting and non-voting jobs? How are they chosen?
> 
> 
>  
> 
> 
>  
> 
> 
> Cheers,
> 
> 
> Marco
> 
> 
>  
> 
> 
> On Fri, 2017-09-22 at 12:10 +, Luke, Chris wrote:
> 
> > I’m sure Vanessa will correct me where I am wrong, but I the suse build was
> > failing on basic things (missing virtualenv) and downvoting otherwise good
> > patches; After I reported this I thought she was going to make them non-
> > voting jobs (since
> >  it I thought I saw somewhere this is what they ought to be), but it seems
> > it was removed from the trigger entirely.
> >  
> > Chris.
> >  
> > 
> > 
> > 
> > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io]
> > On Behalf Of Marco Varlese
> > 
> > Sent: Friday, September 22, 2017 3:29
> > 
> > To: Vanessa Valderrama <vvalderr...@linuxfoundation.org>;
> > infra-steer...@lists.fd.io; 
> > t...@lists.fd.io; disc...@lists.fd.io;
> > vpp-dev@lists.fd.io
> > 
> > Subject: Re: [vpp-dev] [discuss] FD.io Jenkins : 2017-09-21 @ 0430 UTC
> > (9:30am PDT)
> > 
> > 
> >  
> > 
> > Hi Vanessa,
> > 
> > 
> >  
> > 
> > 
> > Did this happen yesterday? I can see VPP being built on CentOS and Ubuntu
> > only.
> > 
> > 
> > 
> >  
> > 
> > 
> > Can you please advice?
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> > 
> > Thanks,
> > 
> > 
> > Marco
> > 
> > 
> >  
> > 
> > 
> > On Thu, 2017-09-21 at 10:57 -0500, Vanessa Valderrama wrote:
> > 
> > > I'll be enabling openSUSE minions for VPP in Jenkins shortly.  I'll be
> > > monitoring VPP builds throughout the day. Please contact me via IRC fdio-
> > > infra (valderrv) if you experience any issues.
> > > When:
> > > 
> > > 2017-09-21 @ 0430 UTC (9:30am PDT)
> > > 
> > > 
> > > 
> > > Thank you,
> > > 
> > > Vanessa
> > > 
> > > On 09/14/2017 11:04 AM, Vanessa Valderrama wrote:
> > > 
> > > > This change will be rescheduled at a later date.
> > > > Thank you,
> > > > 
> > > > Vanessa
> > > > 
> > > > On 09/13/2017 03:34 PM, Vanessa Valderrama wrote:
> > > > 
> > > > > What:
> > > > > 
> > > > > LF is enabling openSUSE minions for VPP jobs in Jenkins
> > > > > When:
> > > > > 
> > > > > 2017-09-14 @ 0500 UTC (10am PDT)
> > > > > 
> > > > > 
> > > > > 
> > > > > Where: 
> > > > > 
> > > > > 
> > > > > 
> > > > > Please contact valderrv via IRC fdio-meeting if you experiene any
> > > > > issue related to this change
> > > > > 
> > > > > Impact:
> > > > > 
> > > > > No restart is required for this change.  Once the change is made VPP
> > > > > jobs will build on openSUSE minions.
> > > > > 
> > > > 
> > > >  
> > > 
> > >  
> > > ___
> > > discuss mailing list
> > > disc...@lists.fd.io
> > > https://lists.fd.io/mailman/listinfo/discuss
> 
> 
> 
> ___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [discuss] FD.io Jenkins : 2017-09-21 @ 0430 UTC (9:30am PDT)

[Marco Varlese]

I think we had the issue with virtualenv before and I thought that was fixed
(zypper in python-virtualenv python3-virtualenv).
Now, since you mentioned something new to me; what's the difference between
voting and non-voting jobs? How are they chosen?

Cheers,Marco
On Fri, 2017-09-22 at 12:10 +, Luke, Chris wrote:
> I’m sure Vanessa will correct me where I am wrong, but I the suse build was
> failing on basic things (missing virtualenv) and downvoting otherwise good
> patches; After I reported this I thought she was going to make them 
> non-voting 
> jobs (since
>  it I thought I saw somewhere this is what they ought to be), but it seems it
> was removed from the trigger entirely.
>  
> Chris.
>  
> 
> 
> 
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io]
> On Behalf Of Marco Varlese
> 
> Sent: Friday, September 22, 2017 3:29
> 
> To: Vanessa Valderrama <vvalderr...@linuxfoundation.org>; infra-steering@lists
> .fd.io; t...@lists.fd.io; disc...@lists.fd.io; vpp-dev@lists.fd.io
> 
> Subject: Re: [vpp-dev] [discuss] FD.io Jenkins : 2017-09-21 @ 0430 UTC (9:30am
> PDT)
> 
> 
>  
> 
> Hi Vanessa,
> 
> 
>  
> 
> 
> Did this happen yesterday? I can see VPP being built on CentOS and Ubuntu
> only.
> 
> 
> 
>  
> 
> 
> Can you please advice?
> 
> 
>  
> 
> 
>  
> 
> 
> Thanks,
> 
> 
> Marco
> 
> 
>  
> 
> 
> On Thu, 2017-09-21 at 10:57 -0500, Vanessa Valderrama wrote:
> 
> > I'll be enabling openSUSE minions for VPP in Jenkins shortly.  I'll be
> > monitoring VPP builds throughout the day. Please contact me via IRC fdio-
> > infra (valderrv) if you experience any issues.
> > When:
> > 
> > 2017-09-21 @ 0430 UTC (9:30am PDT)
> > 
> > 
> > 
> > Thank you,
> > 
> > Vanessa
> > 
> > On 09/14/2017 11:04 AM, Vanessa Valderrama wrote:
> > 
> > > This change will be rescheduled at a later date.
> > > Thank you,
> > > 
> > > Vanessa
> > > 
> > > On 09/13/2017 03:34 PM, Vanessa Valderrama wrote:
> > > 
> > > > What:
> > > > 
> > > > LF is enabling openSUSE minions for VPP jobs in Jenkins
> > > > When:
> > > > 
> > > > 2017-09-14 @ 0500 UTC (10am PDT)
> > > > 
> > > > 
> > > > 
> > > > Where: 
> > > > 
> > > > 
> > > > 
> > > > Please contact valderrv via IRC fdio-meeting if you experiene any issue
> > > > related to this change
> > > > 
> > > > Impact:
> > > > 
> > > > No restart is required for this change.  Once the change is made VPP
> > > > jobs will build on openSUSE minions.
> > > > 
> > > 
> > >  
> > 
> >  
> > ___
> > discuss mailing list
> > disc...@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/discuss
> 
> 
> 
> ___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [discuss] FD.io Jenkins : 2017-09-21 @ 0430 UTC (9:30am PDT)

[Marco Varlese]

Hi Vanessa,
Did this happen yesterday? I can see VPP being built on CentOS and Ubuntu only. 
Can you please advice?

Thanks,Marco
On Thu, 2017-09-21 at 10:57 -0500, Vanessa Valderrama wrote:
> I'll be enabling openSUSE minions for VPP in Jenkins shortly. 
>   I'll be monitoring VPP builds throughout the day. Please contact
>   me via IRC fdio-infra (valderrv) if you experience any issues.
> 
> When:
> 
> 2017-09-21 @ 0430 UTC (9:30am PDT)
> 
> 
> 
> Thank you,
> 
> Vanessa
> 
> 
> 
> On 09/14/2017 11:04 AM, Vanessa
>   Valderrama wrote:
> 
> 
> 
> 
> >   
> >   This change will be rescheduled at a later date.
> >   Thank you,
> > 
> >   Vanessa
> > 
> >   
> > 
> >   On 09/13/2017 03:34 PM, Vanessa
> > Valderrama wrote:
> > 
> >   
> >   
> > > 
> > > What:   
> > > LF
> > >   is enabling openSUSE minions for VPP jobs in Jenkins
> > > 
> > > 
> > > When:   
> > > 2017-09-14
> > >   @ 0500 UTC (10am PDT)
> > > 
> > > 
> > > 
> > > Where: 
> > > 
> > > 
> > > 
> > > Please
> > >   contact valderrv via IRC fdio-meeting if you experiene any
> > >   issue related to this change
> > >   
> > >   
> > > Impact:
> > >  
> > > No restart
> > > is required for this change.  Once the change is made VPP
> > > jobs will build on openSUSE minions. 
> > 
> >   
> > 
> > 
> 
> 
> 
>   
> 
> ___
> discuss mailing list
> disc...@lists.fd.io
> https://lists.fd.io/mailman/listinfo/discuss___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VXLAN tunnel setup on single host?

[Marco Varlese]

Hi John,

On Fri, 2017-09-22 at 05:59 +, John Lo (loj) wrote:
> Hi Marco,
> 
> I am not sure this can work. After VXLAN encap, there is no IP lookup (as it
> is expensive) so it won't naturally follow the IP for-us path to ip4-local and
> ip4-udp-lookup and vxlan-input nodes.  Instead, packet forwarding will follow
> the DPO forwarding chain setup by L3 FIB for the DIP of the VXLAN tunnel. It
> will depends on how the forwarding chain is setup and whether loopback would
> turn around the packet into IP forwarding path properly. 
> 
> From the "show node counters" output, we can see packets are VXLAN encap'ed
> and then dropped because of drop adjacency. You can enable packet trace using
> "trace add vhost-user-input ", send a few packets, and then "show trace".
> The packet trace output should give you pretty good info on how packets are L2
> forwarded, VXLAN encap'ed, forwarded, and dropped to see why it is not working
> and if the forwarding behavior can be changed for your testing purposes.
Thanks for the great hint. Will try this and see where I land :)

> 
> Regards,
> John  
Cheers,
Marco

> 
> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> Behalf Of Marco Varlese
> Sent: Thursday, September 21, 2017 2:51 AM
> To: vpp-dev <vpp-dev@lists.fd.io>
> Subject: [vpp-dev] VXLAN tunnel setup on single host?
> 
> Resending this since it looks like it was never handled by the mail server...
> :(
> 
> On Wed, 2017-09-20 at 16:42 +0200, Marco Varlese wrote:
> > Hi,
> > 
> > I am wondering if it's possible to have a VXLAN setup using a single 
> > host environment.
> > 
> > I thought to use two bridges; each bridge containing:
> > * a virutal interface to be connected to the VM;
> > * a vxlan tunnel interface;
> > * a loop device (with the IP configured as the vxlan tunnel 
> > termination) - guess this might be the issue but do not know what else 
> > to be used :(
> > 
> > Basically, I'd like to be able to send a ping from VM-1 to VM-2 (and 
> > vice-
> > versa) over a vxlan-tunnel. Unfortunately, I didn't succeed and any 
> > help would be really appreciated.
> > 
> > I am doing this since I'm working on a new tunnel protocol and having 
> > a setup on a single host would be simpler for me to setup/maintain in my
> > environment.
> > I chose VXLAN to try out (in this setup) an existing tunnel protocol first.
> > 
> > Below the set of command I am using:
> > 
> > ##
> > #
> > # CREATE TAP interface for VM1
> > $PATH/vppctl create vhost socket /tmp/sock1.sock server $PATH/vppctl 
> > set interface state VirtualEthernet0/0/0 up
> > 
> > # CREATE VXLAN-TUNNEL-0
> > $PATH/vppctl create vxlan tunnel src 10.0.3.1 dst 10.0.3.3 vni 13 
> > decap-next
> > l2 # creates vxlan_tunnel0
> > 
> > # CREATE LOOPBACK interface LOOP0
> > $PATH/vppctl loopback create mac 1a:2b:3c:4d:5e:6f $PATH/vppctl set 
> > interface state loop0 up $PATH/vppctl set interface ip table loop0 5 
> > $PATH/vppctl set interface ip address loop0 10.0.3.1/24
> > 
> > ##
> > #
> > # CREATE TAP interface for VM2
> > $PATH/vppctl create vhost socket /tmp/sock2.sock server $PATH/vppctl 
> > set interface state VirtualEthernet0/0/1 up
> > 
> > # CREATE VXLAN-TUNNEL-1
> > $PATH/vppctl create vxlan tunnel src 10.0.3.3 dst 10.0.3.1 vni 13 
> > decap-next
> > l2 # creates vxlan_tunnel1
> > 
> > # CREATE LOOPBACK interface LOOP1
> > $PATH/vppctl loopback create mac a1:b2:c3:d4:e5:f6 $PATH/vppctl set 
> > interface state loop1 up $PATH/vppctl set interface ip table loop1 5 
> > $PATH/vppctl set interface ip address loop1 10.0.3.3/24
> > 
> > ##
> > # # CREATE bridge-domain 1 with loop0 / vxlan_tunnel0 / tap0 
> > $PATH/vppctl create bridge-domain 1 learn 1 forward 1 uu-flood 1 flood 
> > 1 arp- term 0 $PATH/vppctl set interface l2 bridge 
> > VirtualEthernet0/0/0 1 $PATH/vppctl set interface l2 bridge 
> > vxlan_tunnel0 1 $PATH/vppctl set interface l2 bridge loop0 1 bvi
> > 
> > # CREATE bridge-domain 2 with loop1 / vxlan_tunnel1 / tap1 
> > $PATH/vppctl create bridge-domain 2 learn 1 forward 1 uu-flood 1 flood 
> > 1 arp- term 0 $PATH/vppctl set interface l2 bridge 
> > VirtualEthernet0/0/1 2 $PATH/vppctl set interface l2 bridge 
> > vxlan_tunnel1 2 $PATH/vppctl set in

Re: [vpp-dev] CANCELED - Re: FD.io Enabling Jenkins openSUSE : 2017-09-13 @ 0830 UTC (1:30pm PDT)

[Marco Varlese]

Hi Vanessa / Florin,
Is this something which can proceed now?

Thanks,Marco
On Wed, 2017-09-13 at 15:29 -0500, Vanessa Valderrama wrote:
> Canceling change due to API freeze.
> 
> 
> 
> Thank you,
> 
> Vanessa
> 
> 
> 
> On 09/13/2017 03:19 PM, Florin Coras
>   wrote:
> 
> 
> 
> 
> >   
> >   Vanessa, 
> >   
> > 
> >   
> >   Today is API freeze, could you postpone until
> > tomorrow?
> >   
> > 
> >   
> >   Florin
> >   
> > 
> > 
> >   
> > > On Sep 13, 2017, at 12:55 PM, Vanessa
> > >   Valderrama 
> > >   wrote:
> > > 
> > > 
> > > 
> > >   
> > >   
> > >  
> > > 
> > > 
> > > 
> > >
> > > 
> > >   
> > >   
> > >  
> > > 
> > > 
> > > 
> > >
> > > 
> > >   
> > >   
> > > What:   
> > > LF is enabling
> > >   openSUSE minions for VPP jobs in Jenkins
> > > 
> > > 
> > > When:   
> > > 2017-09-13 @ 0830 UTC
> > >   (1:30pm PDT)
> > > 
> > > 
> > > 
> > > Where: 
> > > 
> > > 
> > > 
> > > Please contact valderrv
> > >   via IRC fdio-meeting if you experiene any
> > >   issue related to this change
> > >   
> > > 
> > > 
> > >   
> > > 
> > > 
> > > Impact:
> > >  
> > > 
> > > 
> > > No restart is required
> > >   for this change.  Once the change is made
> > >   VPP jobs will build on openSUSE minions.
> > > 
> > > 
> > >
> > > 
> > >   
> > > 
> > >   
> > > 
> > >   ___
> > > 
> > >   vpp-dev mailing list
> > > 
> > >   vpp-dev@lists.fd.io
> > > 
> > >   https://lists.fd.io/mailman/listinfo/vpp-dev
> > >   
> > 
> > 
> > 
> > 
> >   
> > 
> 
> 
> 
>   
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VXLAN tunnel setup on single host?

[Marco Varlese]

Resending this since it looks like it was never handled by the mail server... :(

On Wed, 2017-09-20 at 16:42 +0200, Marco Varlese wrote:
> Hi,
> 
> I am wondering if it's possible to have a VXLAN setup using a single host
> environment.
> 
> I thought to use two bridges; each bridge containing:
> * a virutal interface to be connected to the VM;
> * a vxlan tunnel interface;
> * a loop device (with the IP configured as the vxlan tunnel termination) -
> guess this might be the issue but do not know what else to be used :(
> 
> Basically, I'd like to be able to send a ping from VM-1 to VM-2 (and vice-
> versa) over a vxlan-tunnel. Unfortunately, I didn't succeed and any help would
> be really appreciated.
> 
> I am doing this since I'm working on a new tunnel protocol and having a setup
> on a single host would be simpler for me to setup/maintain in my environment.
> I chose VXLAN to try out (in this setup) an existing tunnel protocol first.
> 
> Below the set of command I am using:
> 
> ###
> # CREATE TAP interface for VM1
> $PATH/vppctl create vhost socket /tmp/sock1.sock server
> $PATH/vppctl set interface state VirtualEthernet0/0/0 up
> 
> # CREATE VXLAN-TUNNEL-0
> $PATH/vppctl create vxlan tunnel src 10.0.3.1 dst 10.0.3.3 vni 13 decap-next
> l2 # creates vxlan_tunnel0
> 
> # CREATE LOOPBACK interface LOOP0
> $PATH/vppctl loopback create mac 1a:2b:3c:4d:5e:6f
> $PATH/vppctl set interface state loop0 up
> $PATH/vppctl set interface ip table loop0 5
> $PATH/vppctl set interface ip address loop0 10.0.3.1/24
> 
> ###
> # CREATE TAP interface for VM2
> $PATH/vppctl create vhost socket /tmp/sock2.sock server
> $PATH/vppctl set interface state VirtualEthernet0/0/1 up
> 
> # CREATE VXLAN-TUNNEL-1
> $PATH/vppctl create vxlan tunnel src 10.0.3.3 dst 10.0.3.1 vni 13 decap-next
> l2 # creates vxlan_tunnel1
> 
> # CREATE LOOPBACK interface LOOP1
> $PATH/vppctl loopback create mac a1:b2:c3:d4:e5:f6
> $PATH/vppctl set interface state loop1 up
> $PATH/vppctl set interface ip table loop1 5
> $PATH/vppctl set interface ip address loop1 10.0.3.3/24
> 
> ###
> # CREATE bridge-domain 1 with loop0 / vxlan_tunnel0 / tap0
> $PATH/vppctl create bridge-domain 1 learn 1 forward 1 uu-flood 1 flood 1 arp-
> term 0
> $PATH/vppctl set interface l2 bridge VirtualEthernet0/0/0 1
> $PATH/vppctl set interface l2 bridge vxlan_tunnel0 1
> $PATH/vppctl set interface l2 bridge loop0 1 bvi
> 
> # CREATE bridge-domain 2 with loop1 / vxlan_tunnel1 / tap1
> $PATH/vppctl create bridge-domain 2 learn 1 forward 1 uu-flood 1 flood 1 arp-
> term 0
> $PATH/vppctl set interface l2 bridge VirtualEthernet0/0/1 2
> $PATH/vppctl set interface l2 bridge vxlan_tunnel1 2
> $PATH/vppctl set interface l2 bridge loop1 2 bvi
> 
> $PATH/vppctl set bridge-domain arp term 1
> $PATH/vppctl set bridge-domain arp term 2
> 
> $PATH/vppctl set bridge-domain arp entry 1 10.0.3.1 1a:2b:3c:4d:5e:6f
> $PATH/vppctl set bridge-domain arp entry 2 10.0.3.1 1a:2b:3c:4d:5e:6f
> $PATH/vppctl set bridge-domain arp entry 2 10.0.3.2 a1:b2:c3:d4:e5:f6
> $PATH/vppctl set bridge-domain arp entry 1 10.0.3.2 a1:b2:c3:d4:e5:f6
> 
> 
> Some output I collected when trying to ping from one VM to another.
> DBGvpp# show int
>   Name   Idx   State  Counter  Cou
> nt 
> VirtualEthernet0/0/0  1 up   rx
> packets34
>  rx
> bytes5115
>  drops
>  34
> VirtualEthernet0/0/1  4 up   rx
> packets50
>  rx
> bytes5775
>  drops
>  50
> local00down  
> loop0 3 up   rx
> packets34
>  rx
> bytes4639
>  drops
>  34
>  ip4  
>   9
>  ip6  
>  17
> loop1 6 up   rx
> packets50
>  

Re: [vpp-dev] SIGSEGV when bootstrapping

[Marco Varlese]

When executing VPP - built with the option below - I do get a nice
print of all the misaligned memory being accessed.

Among many, I can also see the one causing the SEGFAULT:

/home/mvarlese/repo/vpp/build-
data/../src/vnet/mfib/mfib_entry.c:405:27: runtime error: member access
within misaligned address 0x7f7703c3cd4c for type 'struct
mfib_entry_t', which requires 64 byte alignment
0x7f7703c3cd4c: note: pointer points here
  01 00 00 00 80 ee c9 03  77 7f 00 00 ff ff ff ff  00 00 00 00 00 00
00 00  00 00 00 00 00 00 00 00
  ^ 
/home/mvarlese/repo/vpp/build-
data/../src/vnet/mfib/mfib_entry.c:406:31: runtime error: member access
within misaligned address 0x7f7703c3cd4c for type 'struct
mfib_entry_t', which requires 64 byte alignment
0x7f7703c3cd4c: note: pointer points here
  01 00 00 00 80 ee c9 03  77 7f 00 00 ff ff ff ff  00 00 00 00 00 00
00 00  00 00 00 00 00 00 00 00


Cheers,
Marco


On Tue, 2017-08-29 at 13:29 +0200, Marco Varlese wrote:
> Dave & all,
> 
> I was suggested by some compiler guys to turn on the gcc option
> -fsanitize=undefined since the error (and the actual way I used to
> fix it) might be caused by unaligned memory.
> 
> I did try that in my local repo and a lot of errors show up for
> src/vppinfra/memcpy_sse3.h regarding a "load/store of misaligned
> address".
> 
> I wonder if this is something we can address?
> 
> I did submit a fix to gerrit but - as suggested - it may only be a
> way
> to workaround the underlying rootcause.
> 
> 
> Cheers,
> Marco
> 
> On Tue, 2017-08-29 at 08:50 +0200, Marco Varlese wrote:
> > Hi Dave,
> > 
> > On Mon, 2017-08-28 at 14:12 -0400, Dave Wallace wrote:
> > > Marco,
> > > 
> > > Thanks for the follow up. Could you please file a Jira for this
> > > issue (https://jira.fd.io/secure/RapidBoard.jspa?rapidView=20
> > > je
> > > ctKey=VPP) and/or submit a patch if you find a workaround?
> > 
> > Sure, I filed the bug and the link is https://jira.fd.io/browse/VPP
> > -9
> > 64
> > I keep digging and hopefully find the solution soon! :)
> > 
> > > Thanks,
> > > -daw-
> > 
> > Cheers,
> > Marco
> > 
> > > On 08/28/2017 12:22 PM, Marco Varlese wrote:
> > > > After long digging I managed to find the issue...
> > > > 
> > > > The problem happens when building VPP using gcc-7 compiler but
> > > > it
> > > > doesn't come up when building it with gcc-6.
> > > > 
> > > > I will keep digging into this but I hope it might be of help to
> > > > you
> > > > folks too...
> > > > 
> > > > 
> > > > Cheers,
> > > > Marco
> > > > 
> > > > On Mon, 2017-08-28 at 16:05 +0200, Marco Varlese wrote:
> > > > > And a even more complete BT with sources below:
> > > > > 
> > > > > [Thread debugging using libthread_db enabled]
> > > > > Using host libthread_db library "/lib64/libthread_db.so.1".
> > > > > vlib_plugin_early_init:356: plugin path
> > > > > /usr/lib64/vpp_plugins
> > > > > load_one_plugin:184: Loaded plugin: acl_plugin.so (Access
> > > > > Control
> > > > > Lists)
> > > > > load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data
> > > > > Plane
> > > > > Development Kit (DPDK))
> > > > > load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow
> > > > > per
> > > > > Packet)
> > > > > load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> > > > > load_one_plugin:184: Loaded plugin: ila_plugin.so
> > > > > (Identifier-
> > > > > locator
> > > > > addressing for IPv6)
> > > > > load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound
> > > > > OAM)
> > > > > load_one_plugin:114: Plugin disabled (default):
> > > > > ixge_plugin.so
> > > > > load_one_plugin:184: Loaded plugin: lb_plugin.so (Load
> > > > > Balancer)
> > > > > load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6
> > > > > Rapid
> > > > > Deployment on IPv4 Infrastructure (RFC5969))
> > > > > load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet
> > > > > Memory
> > > > > Interface (experimetal))
> > > > > load_one_plugin:184: Loaded plugin: nat_plugin.so (Network
> > > > > Address
> > > > > Translation)
> > >

Re: [vpp-dev] SIGSEGV when bootstrapping

[Marco Varlese]

Dave & all,

I was suggested by some compiler guys to turn on the gcc option
-fsanitize=undefined since the error (and the actual way I used to fix it) 
might be caused by unaligned memory.

I did try that in my local repo and a lot of errors show up for
src/vppinfra/memcpy_sse3.h regarding a "load/store of misaligned
address".

I wonder if this is something we can address?

I did submit a fix to gerrit but - as suggested - it may only be a way
to workaround the underlying rootcause.


Cheers,
Marco

On Tue, 2017-08-29 at 08:50 +0200, Marco Varlese wrote:
> Hi Dave,
> 
> On Mon, 2017-08-28 at 14:12 -0400, Dave Wallace wrote:
> > Marco,
> > 
> > Thanks for the follow up. Could you please file a Jira for this
> > issue (https://jira.fd.io/secure/RapidBoard.jspa?rapidView=20
> > ctKey=VPP) and/or submit a patch if you find a workaround?
> 
> Sure, I filed the bug and the link is https://jira.fd.io/browse/VPP-9
> 64
> I keep digging and hopefully find the solution soon! :)
> 
> > Thanks,
> > -daw-
> 
> Cheers,
> Marco
> 
> > On 08/28/2017 12:22 PM, Marco Varlese wrote:
> > > After long digging I managed to find the issue...
> > > 
> > > The problem happens when building VPP using gcc-7 compiler but it
> > > doesn't come up when building it with gcc-6.
> > > 
> > > I will keep digging into this but I hope it might be of help to
> > > you
> > > folks too...
> > > 
> > > 
> > > Cheers,
> > > Marco
> > > 
> > > On Mon, 2017-08-28 at 16:05 +0200, Marco Varlese wrote:
> > > > And a even more complete BT with sources below:
> > > > 
> > > > [Thread debugging using libthread_db enabled]
> > > > Using host libthread_db library "/lib64/libthread_db.so.1".
> > > > vlib_plugin_early_init:356: plugin path /usr/lib64/vpp_plugins
> > > > load_one_plugin:184: Loaded plugin: acl_plugin.so (Access
> > > > Control
> > > > Lists)
> > > > load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane
> > > > Development Kit (DPDK))
> > > > load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow
> > > > per
> > > > Packet)
> > > > load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> > > > load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-
> > > > locator
> > > > addressing for IPv6)
> > > > load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound
> > > > OAM)
> > > > load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> > > > load_one_plugin:184: Loaded plugin: lb_plugin.so (Load
> > > > Balancer)
> > > > load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6
> > > > Rapid
> > > > Deployment on IPv4 Infrastructure (RFC5969))
> > > > load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet
> > > > Memory
> > > > Interface (experimetal))
> > > > load_one_plugin:184: Loaded plugin: nat_plugin.so (Network
> > > > Address
> > > > Translation)
> > > > load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
> > > > 
> > > > Program received signal SIGSEGV, Segmentation fault.
> > > > mfib_entry_alloc (mfib_entry_index=,
> > > > prefix=0x7fffb60f0ce0, fib_index=0) at /usr/src/debug/vpp-
> > > > 17.10/src/vnet/mfib/mfib_entry.c:407
> > > > 407 mfib_entry->mfe_prefix = *prefix;
> > > > Missing separate debuginfos, use: zypper install libdpdk-17_08-
> > > > 0-
> > > > debuginfo-17.08-82.1.x86_64 libnuma1-debuginfo-2.0.9-
> > > > 10.2.x86_64
> > > > libopenssl1_0_0-debuginfo-1.0.2j-6.3.1.x86_64 libz1-debuginfo-
> > > > 1.2.8-
> > > > 10.1.x86_64 vpp-plugins-debuginfo-17.10-14.2.x86_64
> > > > 
> > > > (gdb) bt
> > > > #0  mfib_entry_alloc (mfib_entry_index=,
> > > > prefix=0x7fffb60f0ce0, fib_index=0) at /usr/src/debug/vpp-
> > > > 17.10/src/vnet/mfib/mfib_entry.c:407
> > > > #1  mfib_entry_create (fib_index=fib_index@entry=0, source=sour
> > > > ce@ent
> > > > ry
> > > > =MFIB_SOURCE_DEFAULT_ROUTE, prefix=prefix@entry=0x7fffb60f0ce0,
> > > > rpf_id=
> > > > rpf_id@entry=0, entry_flags=entry_flags@entry=MFIB_ENTRY_FLAG_D
> > > > ROP)
> > > > at /usr/src/debug/vpp-17.10/src/vnet/mfib/mfib_entry.c:719
> > > > #2  0x7765cdc7 in mfib_table_entr

Re: [vpp-dev] SIGSEGV when bootstrapping

[Marco Varlese]

Hi Dave,
On Mon, 2017-08-28 at 14:12 -0400, Dave Wallace wrote:
> Marco,
> 
>   
> 
>   Thanks for the follow up. Could you please file a Jira for this
>   issue
> (https://jira.fd.io/secure/RapidBoard.jspa?rapidView=20=VP
> P)
>   and/or submit a patch if you find a workaround?
Sure, I filed the bug and the link is https://jira.fd.io/browse/VPP-964
I keep digging and hopefully find the solution soon! :)
>   
> 
>   Thanks,
> 
>   -daw-
Cheers,Marco
> 
> 
> On 08/28/2017 12:22 PM, Marco Varlese
>   wrote:
> 
> 
> 
> >   After long digging I managed to find the issue...
> > 
> > The problem happens when building VPP using gcc-7 compiler but it
> > doesn't come up when building it with gcc-6.
> > 
> > I will keep digging into this but I hope it might be of help to you
> > folks too...
> > 
> > 
> > Cheers,
> > Marco
> > 
> > On Mon, 2017-08-28 at 16:05 +0200, Marco Varlese wrote:
> > 
> >   
> > > And a even more complete BT with sources below:
> > > 
> > > [Thread debugging using libthread_db enabled]
> > > Using host libthread_db library "/lib64/libthread_db.so.1".
> > > vlib_plugin_early_init:356: plugin path /usr/lib64/vpp_plugins
> > > load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control
> > > Lists)
> > > load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane
> > > Development Kit (DPDK))
> > > load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per
> > > Packet)
> > > load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> > > load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-
> > > locator
> > > addressing for IPv6)
> > > load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> > > load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> > > load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> > > load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6
> > > Rapid
> > > Deployment on IPv4 Infrastructure (RFC5969))
> > > load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet
> > > Memory
> > > Interface (experimetal))
> > > load_one_plugin:184: Loaded plugin: nat_plugin.so (Network
> > > Address
> > > Translation)
> > > load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > mfib_entry_alloc (mfib_entry_index=,
> > > prefix=0x7fffb60f0ce0, fib_index=0) at /usr/src/debug/vpp-
> > > 17.10/src/vnet/mfib/mfib_entry.c:407
> > > 407   mfib_entry->mfe_prefix = *prefix;
> > > Missing separate debuginfos, use: zypper install libdpdk-17_08-0-
> > > debuginfo-17.08-82.1.x86_64 libnuma1-debuginfo-2.0.9-10.2.x86_64
> > > libopenssl1_0_0-debuginfo-1.0.2j-6.3.1.x86_64 libz1-debuginfo-
> > > 1.2.8-
> > > 10.1.x86_64 vpp-plugins-debuginfo-17.10-14.2.x86_64
> > > 
> > > (gdb) bt
> > > #0  mfib_entry_alloc (mfib_entry_index=,
> > > prefix=0x7fffb60f0ce0, fib_index=0) at /usr/src/debug/vpp-
> > > 17.10/src/vnet/mfib/mfib_entry.c:407
> > > #1  mfib_entry_create (fib_index=fib_index@entry=0, source=source
> > > @ent
> > > ry
> > > =MFIB_SOURCE_DEFAULT_ROUTE, prefix=prefix@entry=0x7fffb60f0ce0,
> > > rpf_id=
> > > rpf_id@entry=0, entry_flags=entry_flags@entry=MFIB_ENTRY_FLAG_DRO
> > > P)
> > > at /usr/src/debug/vpp-17.10/src/vnet/mfib/mfib_entry.c:719
> > > #2  0x7765cdc7 in mfib_table_entry_update (fib_index=0,
> > > prefix=
> > > prefix@entry=0x7fffb60f0ce0, source=source@entry=MFIB_SOURCE_DEFA
> > > ULT_
> > > RO
> > > UTE, rpf_id=rpf_id@entry=0, 
> > > entry_flags=entry_flags@entry=MFIB_ENTRY_FLAG_DROP) at
> > > /usr/src/debug/vpp-17.10/src/vnet/mfib/mfib_table.c:184
> > > #3  0x77656b85 in ip4_create_mfib_with_table_id
> > > (table_id=0)
> > > at
> > > /usr/src/debug/vpp-17.10/src/vnet/mfib/ip4_mfib.c:72
> > > #4  ip4_mfib_table_find_or_create_and_lock (table_id=table_id@ent
> > > ry=0
> > > )
> > > at /usr/src/debug/vpp-17.10/src/vnet/mfib/ip4_mfib.c:122
> > > #5  0x7765d257 in mfib_table_find_or_create_and_lock
> > > (proto=pro
> > > to@entry=FIB_PROTOCOL_IP4, table_id=table_id@entry=0) at
> > > /usr/src/debug/vpp-17.10/src/vnet/mfib/mfib_table.c

Re: [vpp-dev] SIGSEGV when bootstrapping

[Marco Varlese]

After long digging I managed to find the issue...

The problem happens when building VPP using gcc-7 compiler but it
doesn't come up when building it with gcc-6.

I will keep digging into this but I hope it might be of help to you
folks too...


Cheers,
Marco

On Mon, 2017-08-28 at 16:05 +0200, Marco Varlese wrote:
> And a even more complete BT with sources below:
> 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> vlib_plugin_early_init:356: plugin path /usr/lib64/vpp_plugins
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control
> Lists)
> load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane
> Development Kit (DPDK))
> load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per
> Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid
> Deployment on IPv4 Infrastructure (RFC5969))
> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory
> Interface (experimetal))
> load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address
> Translation)
> load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
> 
> Program received signal SIGSEGV, Segmentation fault.
> mfib_entry_alloc (mfib_entry_index=,
> prefix=0x7fffb60f0ce0, fib_index=0) at /usr/src/debug/vpp-
> 17.10/src/vnet/mfib/mfib_entry.c:407
> 407   mfib_entry->mfe_prefix = *prefix;
> Missing separate debuginfos, use: zypper install libdpdk-17_08-0-
> debuginfo-17.08-82.1.x86_64 libnuma1-debuginfo-2.0.9-10.2.x86_64
> libopenssl1_0_0-debuginfo-1.0.2j-6.3.1.x86_64 libz1-debuginfo-1.2.8-
> 10.1.x86_64 vpp-plugins-debuginfo-17.10-14.2.x86_64
> 
> (gdb) bt
> #0  mfib_entry_alloc (mfib_entry_index=,
> prefix=0x7fffb60f0ce0, fib_index=0) at /usr/src/debug/vpp-
> 17.10/src/vnet/mfib/mfib_entry.c:407
> #1  mfib_entry_create (fib_index=fib_index@entry=0, source=source@ent
> ry
> =MFIB_SOURCE_DEFAULT_ROUTE, prefix=prefix@entry=0x7fffb60f0ce0,
> rpf_id=
> rpf_id@entry=0, entry_flags=entry_flags@entry=MFIB_ENTRY_FLAG_DROP)
> at /usr/src/debug/vpp-17.10/src/vnet/mfib/mfib_entry.c:719
> #2  0x7765cdc7 in mfib_table_entry_update (fib_index=0,
> prefix=
> prefix@entry=0x7fffb60f0ce0, source=source@entry=MFIB_SOURCE_DEFAULT_
> RO
> UTE, rpf_id=rpf_id@entry=0, 
> entry_flags=entry_flags@entry=MFIB_ENTRY_FLAG_DROP) at
> /usr/src/debug/vpp-17.10/src/vnet/mfib/mfib_table.c:184
> #3  0x77656b85 in ip4_create_mfib_with_table_id (table_id=0)
> at
> /usr/src/debug/vpp-17.10/src/vnet/mfib/ip4_mfib.c:72
> #4  ip4_mfib_table_find_or_create_and_lock (table_id=table_id@entry=0
> )
> at /usr/src/debug/vpp-17.10/src/vnet/mfib/ip4_mfib.c:122
> #5  0x7765d257 in mfib_table_find_or_create_and_lock
> (proto=pro
> to@entry=FIB_PROTOCOL_IP4, table_id=table_id@entry=0) at
> /usr/src/debug/vpp-17.10/src/vnet/mfib/mfib_table.c:435
> #6  0x77338b14 in ip4_lookup_init (vm=vm@entry=0x77bb62e0
> ) at /usr/src/debug/vpp-
> 17.10/src/vnet/ip/ip4_forward.c:1202
> #7  0x77273bff in vnet_main_init (vm=vm@entry=0x77bb62e0
> ) at /usr/src/debug/vpp-17.10/src/vnet/misc.c:92
> #8  0x773a4507 in ip_main_init (vm=0x77bb62e0
> ) at /usr/src/debug/vpp-
> 17.10/src/vnet/ip/ip_init.c:104
> #9  0x7fffb35d8572 in ?? () from
> /usr/lib64/vpp_plugins/ioam_plugin.so
> #10 0x7796128d in vlib_call_init_exit_functions
> (vm=0x77bb62e0 , head=,
> call_once=
> call_once@entry=1) at /usr/src/debug/vpp-17.10/src/vlib/init.c:57
> #11 0x779612d3 in vlib_call_all_init_functions (vm= out>) at /usr/src/debug/vpp-17.10/src/vlib/init.c:75
> #12 0x779657a5 in vlib_main (vm=, vm@entry=0x7
> ff
> ff7bb62e0 , input=input@entry=0x7fffb60f0fa0) at
> /usr/src/debug/vpp-17.10/src/vlib/main.c:1754
> #13 0x7799d3c6 in thread0 (arg=140737349640928) at
> /usr/src/debug/vpp-17.10/src/vlib/unix/main.c:525
> #14 0x76f7a250 in clib_calljmp () at /usr/src/debug/vpp-
> 17.10/src/vppinfra/longjmp.S:110
> #15 0x7fffd100 in ?? ()
> #16 0x7799df54 in vlib_unix_main (argc=,
> argv=) at /usr/src/debug/vpp-
> 17.10/src/vlib/unix/main.c:588
> #17 0x in ?? ()
> 
> 
> 
> Regards,
> Marco
> 
> On Mon, 2017-08-28 at 15:41 +0200, Marco Varlese wrote:
> > Apologies, I forgot to also provide some extra information:
&

Re: [vpp-dev] SIGSEGV when bootstrapping

[Marco Varlese]

Apologies, I forgot to also provide some extra information:

> Using DPDK 17.08.

> A backtrace below:

(gdb) bt
#0  0x7765bced in mfib_entry_create () from
/usr/lib64/libvnet.so.0
#1  0x7765cdc7 in mfib_table_entry_update () from
/usr/lib64/libvnet.so.0
#2  0x77656b85 in ip4_mfib_table_find_or_create_and_lock ()
from /usr/lib64/libvnet.so.0
#3  0x7765d257 in mfib_table_find_or_create_and_lock () from
/usr/lib64/libvnet.so.0
#4  0x77338b14 in ip4_lookup_init () from
/usr/lib64/libvnet.so.0
#5  0x77273bff in vnet_main_init () from
/usr/lib64/libvnet.so.0
#6  0x773a4507 in ip_main_init () from /usr/lib64/libvnet.so.0
#7  0x7fffb35d8572 in ?? () from
/usr/lib64/vpp_plugins/ioam_plugin.so
#8  0x7796128d in vlib_call_init_exit_functions () from
/usr/lib64/libvlib.so.0
#9  0x779657a5 in vlib_main () from /usr/lib64/libvlib.so.0
#10 0x7799d3c6 in ?? () from /usr/lib64/libvlib.so.0
#11 0x76f7a250 in clib_calljmp () from
/usr/lib64/libvppinfra.so.0
#12 0x7fffd0f0 in ?? ()
#13 0x7799df54 in vlib_unix_main () from
/usr/lib64/libvlib.so.0
#14 0x in ?? ()


Cheers,
Marco

On Mon, 2017-08-28 at 15:10 +0200, Marco Varlese wrote:
> Hi,
> 
> I'm running the tip of master branch and I get a segmentation fault
> when launcing "vpp -c /etc/vpp/startup.conf"
> 
> My startup.conf is very simple, I don't even map dpdk interfaces,
> etc.
> since I am using in a virt environment.
> 
> I wonder if by any chance a new setting/parameter was introduced
> which
> I am missing hence having such an issue?
> 
> The stacktrace of the execution is below.
> 
> load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane
> Development Kit (DPDK))
> load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per
> Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid
> Deployment on IPv4 Infrastructure (RFC5969))
> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory
> Interface (experimetal))
> load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address
> Translation)
> load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
> 
> Program received signal SIGSEGV, Segmentation fault.
> mfib_entry_alloc (mfib_entry_index=,
> prefix=0x7f1219818ce0, fib_index=0) at /usr/src/debug/vpp-
> 17.10/src/vnet/mfib/mfib_entry.c:407
> 407   mfib_entry->mfe_prefix = *prefix;
> (gdb) 
> 
> 
> 
> Thanks,
> Marco
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] SIGSEGV when bootstrapping

[Marco Varlese]

Hi,

I'm running the tip of master branch and I get a segmentation fault
when launcing "vpp -c /etc/vpp/startup.conf"

My startup.conf is very simple, I don't even map dpdk interfaces, etc.
since I am using in a virt environment.

I wonder if by any chance a new setting/parameter was introduced which
I am missing hence having such an issue?

The stacktrace of the execution is below.

load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane
Development Kit (DPDK))
load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per
Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid
Deployment on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory
Interface (experimetal))
load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address
Translation)
load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)

Program received signal SIGSEGV, Segmentation fault.
mfib_entry_alloc (mfib_entry_index=,
prefix=0x7f1219818ce0, fib_index=0) at /usr/src/debug/vpp-
17.10/src/vnet/mfib/mfib_entry.c:407
407 mfib_entry->mfe_prefix = *prefix;
(gdb) 



Thanks,
Marco

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Marco Varlese]

On Mon, 2017-08-14 at 09:50 +0100, Sergio Gonzalez Monroy wrote:
> 
> On 14/08/2017 09:46, Marco Varlese
>   wrote:
> 
> 
> 
> >   
> >   On Mon, 2017-08-14 at 09:37 +0100, Sergio Gonzalez Monroy
> > wrote:
> > 
> > > On 14/08/2017 09:25, Marco Varlese
> > >   wrote:
> > > 
> > > 
> > > 
> > > >   On Mon, 2017-08-14 at 08:17 +0100, Sergio Gonzalez Monroy
> > > > wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > >   
> > > > > 
> > > > >   So I gather that:
> > > > > 
> > > > >   1. DPDK and the SW crypto libraries are building without
> > > > >   errors
> > > > > 
> > > > >   2. Only OpenSUSE displays this behavior.
> > > > > 
> > > > >   
> > > > > 
> > > > > > > > > >   Only thing I can think of is that configure 
> > > > > > > > > > has
different
> > > > >   default libdir directory in OpenSUSE?
> > > > > 
> > > > >   
> > > > > 
> > > > >   Could you show the output of the following command:
> > > > > 
> > > > >   grep "libdir:" 
> > > > > > > > > > 
> > > > > > > > > > build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
2.18.0/config.log
> > > > > 
> > > > >   
> > > > > 
> > > > > > > > > >   Regarding the option 
> > > > > > > > > > vpp_uses_dpdk_cryptodev_sw=yes, it
is
> > > > >   indeed not used anymore but I obviously missed some
> > > > >   cleanup.
> > > > > 
> > > > > 
> > > > > 
> > > >   
> > > > 
> > > >   
> > > > 
> > > >   Is the latest code (post 17.05) requiring a specific IA
> > > > platf

Re: [vpp-dev] Issues building latest master

[Marco Varlese]

 > 
  
  > > > > > > After updating my nasm, I am seeing the very same
problem Marco is seeing. On openSUSE 42.3. Not seen on CentOS 7.
Not seen on my VyOS system.
> > 



> > Burt

  

  > > > > > > 

> > > > > > > > On Fri, Aug 11, 2017 at 10:36 AM, Marco
  Varlese > > > > <marco.varl...@suse.com>
  wrote:

  > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > Hi,



I am having troubles building the latest code off the master
branch.



The commands I always use are:

> make bootstrap

> make build



I get this error:

cp: cannot stat 
'/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-

l_crypto-2.18.0/install/lib/libisal_crypto.a': No such
file or directory



I noticed that once the compilation of DPDK completes the
libraries - as

suggested by the build process itself - are placed at:

/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-l_crypto-

2.18.0/install/lib64



So it looks like somewhere the build system is using "lib64"
and in another

place just "lib".



I wonder if something has changed and - in that case - what
shall I do?



Also, I noticed that setting the vpp_uses_dpdk_cryptodev_sw
= no in build-

date/platforms/vpp.mk
has no effect (e.g. whether yes or no the build process

still builds the crypto stuff from DPDK). Is this a known
behaviour?





Cheers,

Marco

___

vpp-dev mailing list

vpp-dev@lists.fd.io

https://lists.fd.io/mailman/listinfo/vpp-dev

  





  

  

  
  

  > > > > ___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev



> 



  

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Marco Varlese]

Hi Sergio,

I tried on a different machine and I got this:

libdir: ${exec_prefix}/lib64

Thanks,
Marco


>>> Marco Varlese 08/14/17 10:04 AM >>>



>>> Sergio Gonzalez Monroy <sergio.gonzalez.mon...@intel.com> 08/14/17 9:17 AM 
>>> >>>
> Hi,
>
> So I gather that:
> 1. DPDK and the SW crypto libraries are building without errors
> 2. Only OpenSUSE displays this behavior.
> 
> Only thing I can think of is that configure has different default libdir 
> directory in OpenSUSE?
> 
> Could you show the output of the following command:
> grep "libdir:" 
> build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
>
mvarlese@linux-yk3w:~/repos/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
grep: build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log: No 
such file or directory

> Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed not 
> used anymore but I obviously missed some cleanup.
> 
> Thanks,
> Sergio


On 11/08/2017 20:25, Burt Silverman wrote:
> After updating my nasm, I am seeing the very same problem Marco is 
> seeing. On openSUSE 42.3. Not seen on CentOS 7. Not seen on my VyOS 
> system.
>
> Burt
>
> On Fri, Aug 11, 2017 at 10:36 AM, Marco Varlese 
> <marco.varl...@suse.com <mailto:marco.varl...@suse.com>> wrote:
>
> Hi,
>
> I am having troubles building the latest code off the master branch.
>
> The commands I always use are:
> > make bootstrap
> > make build
>
> I get this error:
> cp: cannot stat
> '/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-
> l_crypto-2.18.0/install/lib/libisal_crypto.a': No such file or
> directory
>
> I noticed that once the compilation of DPDK completes the
> libraries - as
> suggested by the build process itself - are placed at:
> /home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
> 2.18.0/install/lib64
>
> So it looks like somewhere the build system is using "lib64" and
> in another
> place just "lib".
>
> I wonder if something has changed and - in that case - what shall
> I do?
>
> Also, I noticed that setting the vpp_uses_dpdk_cryptodev_sw = no
> in build-
> date/platforms/vpp.mk <http://vpp.mk> has no effect (e.g. whether
> yes or no the build process
> still builds the crypto stuff from DPDK). Is this a known behaviour?
>
>
> Cheers,
> Marco
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> https://lists.fd.io/mailman/listinfo/vpp-dev
> <https://lists.fd.io/mailman/listinfo/vpp-dev>
>
>
>
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev




marco@linux-3s68:~/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
libdir: ${exec_prefix}/lib64


marco@linux-3s68:~/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
libdir: ${exec_prefix}/lib64






___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Marco Varlese]

>>> Sergio Gonzalez Monroy <sergio.gonzalez.mon...@intel.com> 08/14/17 9:17 AM 
>>> >>>
> Hi,
>
> So I gather that:
> 1. DPDK and the SW crypto libraries are building without errors
> 2. Only OpenSUSE displays this behavior.
> 
> Only thing I can think of is that configure has different default libdir 
> directory in OpenSUSE?
> 
> Could you show the output of the following command:
> grep "libdir:" 
> build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
>
mvarlese@linux-yk3w:~/repos/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
grep: build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log: No 
such file or directory

> Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed not 
> used anymore but I obviously missed some cleanup.
> 
> Thanks,
> Sergio


On 11/08/2017 20:25, Burt Silverman wrote:
> After updating my nasm, I am seeing the very same problem Marco is 
> seeing. On openSUSE 42.3. Not seen on CentOS 7. Not seen on my VyOS 
> system.
>
> Burt
>
> On Fri, Aug 11, 2017 at 10:36 AM, Marco Varlese 
> <marco.varl...@suse.com <mailto:marco.varl...@suse.com>> wrote:
>
> Hi,
>
> I am having troubles building the latest code off the master branch.
>
> The commands I always use are:
> > make bootstrap
> > make build
>
> I get this error:
> cp: cannot stat
> '/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-
> l_crypto-2.18.0/install/lib/libisal_crypto.a': No such file or
> directory
>
> I noticed that once the compilation of DPDK completes the
> libraries - as
> suggested by the build process itself - are placed at:
> /home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
> 2.18.0/install/lib64
>
> So it looks like somewhere the build system is using "lib64" and
> in another
> place just "lib".
>
> I wonder if something has changed and - in that case - what shall
> I do?
>
> Also, I noticed that setting the vpp_uses_dpdk_cryptodev_sw = no
> in build-
> date/platforms/vpp.mk <http://vpp.mk> has no effect (e.g. whether
> yes or no the build process
> still builds the crypto stuff from DPDK). Is this a known behaviour?
>
>
> Cheers,
> Marco
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> https://lists.fd.io/mailman/listinfo/vpp-dev
> <https://lists.fd.io/mailman/listinfo/vpp-dev>
>
>
>
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev





___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Issues building latest master

[Marco Varlese]

Hi,

I am having troubles building the latest code off the master branch.

The commands I always use are:
> make bootstrap
> make build

I get this error:
cp: cannot stat '/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-
l_crypto-2.18.0/install/lib/libisal_crypto.a': No such file or directory

I noticed that once the compilation of DPDK completes the libraries - as
suggested by the build process itself - are placed at:
/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
2.18.0/install/lib64

So it looks like somewhere the build system is using "lib64" and in another
place just "lib".

I wonder if something has changed and - in that case - what shall I do?

Also, I noticed that setting the vpp_uses_dpdk_cryptodev_sw = no in build-
date/platforms/vpp.mk has no effect (e.g. whether yes or no the build process
still builds the crypto stuff from DPDK). Is this a known behaviour?


Cheers,
Marco
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Bind / Unbind of ACL

[Marco Varlese]

On Sat, 2017-06-17 at 11:27 +0200, Andrew   Yourtchenko wrote:
> Perfect, thanks a lot!
> 
> I've pushed the update https://gerrit.fd.io/r/#/c/6858/10 which
> codifies all of our discussion.
> 
> With that change, both applying an inexistent ACL and deleting the ACL
> that is applied somewhere will be an error.
> 
> One can still create an ACL with no rules, in which case applying that
> ACL will follow the lookup logic with the default-deny in the end of
> the vector of ACLs lookup.
+1

> 
> --a
> 
> On 6/17/17, Luke, Chris <chris_l...@comcast.com> wrote:
> > 
> > That was going to be one of my queries, but forgot to ask. Do we allow that
> > currently? Probably shouldn't, as you say, for symmetry.
> > 
> > Chris.
> > 
> > > 
> > > -Original Message-
> > > From: Andrew Yourtchenko [mailto:ayour...@gmail.com]
> > > Sent: Friday, June 16, 2017 17:51
> > > To: Luke, Chris <chris_l...@cable.comcast.com>
> > > Cc: Marco Varlese <marco.varl...@suse.com>; vpp-dev@lists.fd.io
> > > Subject: Re: [vpp-dev] Bind / Unbind of ACL
> > > 
> > > Ok! So what do you think if then we were to also disallow applying the
> > > ACL
> > > that doesn't exist yet ?
> > > 
> > > It feels like it would be a matching symmetric behavior "from the other
> > > side".
> > > ?
> > > 
> > > --a
> > > 
> > > On 16 Jun 2017, at 15:38, Luke, Chris <chris_l...@comcast.com> wrote:
> > > 
> > > > 
> > > > > 
> > > > > From: Marco Varlese [mailto:marco.varl...@suse.com]
> > > > > Sent: Friday, June 16, 2017 9:23
> > > > > > 
> > > > > > On Fri, 2017-06-16 at 15:12 +0200, Andrew   Yourtchenko wrote:
> > > > > > > 
> > > > > > > On 6/16/17, Marco Varlese <marco.varl...@suse.com> wrote:
> > > > > > > 
> > > > > > > > 
> > > > > > > > On Thu, 2017-06-15 at 14:22 +0200, Andrew   Yourtchenko wrote:
> > > > > > > > 
> > > > > > > > After a bit more thinking - there is a way that should take care
> > > > > > > > of
> > > > > > > > both:
> > > > > > > > 
> > > > > > > > 1) What Chris wrote: have consistent behaviour with non-existent
> > > > > > > > ACL as if the ACL matching fell off the end of the ACL: if an
> > > > > > > > empty ACL is referenced, treat it as if it had entries but none
> > > > > > > > of
> > > > > > > > them had matched. Then we still hit the "default deny" if none
> > > > > > > > of
> > > > > > > > the applied ACLs match, and drop the packets - so it will be
> > > > > > > > logical.
> > > > > > > > 
> > > > > > > > 2) What Marco wrote: when deleting an already referenced ACL,
> > > > > > > > unapply it from all the places where it is applied.
> > > > > > > > 
> > > > > > > > It's a change in the behaviour in that the current behaviour is
> > > > > > > > to
> > > > > > > > have the empty ACL act as if it was "deny any any", and block
> > > > > > > > the
> > > > > > > > matching even if there is another ACL after it - but on the
> > > > > > > > other
> > > > > > > > hand this would take both viewpoints in mind...
> > > > > > > I think this approach would still leave the system in an
> > > > > > > inconsistent
> > > state:
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > an
> > > > > > > interface is basically assigned an ACL which does not exist in the
> > > system.
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > Also, the risk I see is if I later on create an ACL with the
> > > > > > > previously used index then an interface would see that ACL being
> > > > > > > applied automatically (since it's referenced). However, I may not
> > > > > > > wan

Re: [vpp-dev] Bind / Unbind of ACL

[Marco Varlese]

On Fri, 2017-06-16 at 15:12 +0200, Andrew   Yourtchenko wrote:
> On 6/16/17, Marco Varlese <marco.varl...@suse.com> wrote:
> > 
> > On Thu, 2017-06-15 at 14:22 +0200, Andrew   Yourtchenko wrote:
> > > 
> > > After a bit more thinking - there is a way that should take care of both:
> > > 
> > > 1) What Chris wrote: have consistent behaviour with non-existent ACL
> > > as if the ACL matching fell off the end of the ACL: if an empty ACL is
> > > referenced, treat it as if it had entries but none of them had
> > > matched. Then we still hit the "default deny" if none of the applied
> > > ACLs match, and drop the packets - so it will be logical.
> > > 
> > > 2) What Marco wrote: when deleting an already referenced ACL, unapply
> > > it from all the places where it is applied.
> > > 
> > > It's a change in the behaviour in that the current behaviour is to
> > > have the empty ACL act as if it was "deny any any", and block the
> > > matching even if there is another ACL after it - but on the other hand
> > > this would take both viewpoints in mind...
> > I think this approach would still leave the system in an inconsistent state:
> > an
> > interface is basically assigned an ACL which does not exist in the system.
> > Also, the risk I see is if I later on create an ACL with the previously
> > used
> > index then an interface would see that ACL being applied automatically
> > (since
> > it's referenced). However, I may not want to have that ACL assigned to that
> > particular interface. Correct?
> > 
> > I think that the "deletion" of an ACL could see one of the two behaviours
> > below:
> > 1) the deletion of an ACL should be DENIED if that ACL is assigned to any
> > interface (probably the easier and safer approach);
> > 2) the deletion of an ACL should see a CASCADING effect onto the interfaces
> > which would be "cleaned up" of any references to that ACL;
> > 
> 
> Right, the (2) was what I was trying to suggest to do...
> 
> > 
> > I think (1) is a very good way of solving the initial problem since it
> > works
> > nicely if you manage VPP directly (e.g. via command-line) and if you use a
> > controller. In the latter, the controller can react on the "error" returned
> > by
> > the acl_del API because that ACL is assigned somewhere.
> > 
> 
> ...but the (1) is another good option to me.
> 
> So it seems we are converging on (1) ?
I would go with (1)...
> 
> --a
> 
> 
> 
> > 
> > 
> > Cheers,
> > Marco
> > 
> > > 
> > > 
> > > What do you think ?
> > > 
> > > --a
> > > 
> > > On 6/9/17, Andrew   Yourtchenko <ayour...@gmail.com> wrote:
> > > > 
> > > > 
> > > > Assuming the only change is to effectively have
> > > > "unbind_acl_from_everywhere; delete_acl" instead of "delete_acl",
> > > > maybe it would be best to tackle that post-17.07 with a separate API
> > > > message acl_del_and_unbind or similar ?
> > > > 
> > > > I feel a beet wary of adding more hidden state (even though the
> > > > reflected sessions table does provide already plenty of it :)
> > > > 
> > > > --a
> > > > 
> > > > On 6/9/17, Luke, Chris <chris_l...@comcast.com> wrote:
> > > > > 
> > > > > 
> > > > > Would it make sense to have a flag on the interface (or globally),
> > > > > set
> > > > > when
> > > > > applying the ACL, that indicates the desired behavior when the ACL is
> > > > > empty
> > > > > or non-existent? At the moment to me it seems logical that this is
> > > > > the
> > > > > same
> > > > > behavior as when matching falls off the end of the ACL.
> > > > > 
> > > > > Chris.
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > -Original Message-
> > > > > > From: vpp-dev-boun...@lists.fd.io
> > > > > > [mailto:vpp-dev-boun...@lists.fd.io]
> > > > > > On
> > > > > > Behalf Of Andrew ?? Yourtchenko
> > > > > > Sent: Friday, June 9, 2017 7:53
> > > > > > To: Marco Varlese <marco.varl...@suse.com>
> > > > > > Cc: vpp-dev@lists.fd.io
> 

Re: [vpp-dev] Bind / Unbind of ACL

[Marco Varlese]

On Thu, 2017-06-15 at 14:22 +0200, Andrew   Yourtchenko wrote:
> After a bit more thinking - there is a way that should take care of both:
> 
> 1) What Chris wrote: have consistent behaviour with non-existent ACL
> as if the ACL matching fell off the end of the ACL: if an empty ACL is
> referenced, treat it as if it had entries but none of them had
> matched. Then we still hit the "default deny" if none of the applied
> ACLs match, and drop the packets - so it will be logical.
> 
> 2) What Marco wrote: when deleting an already referenced ACL, unapply
> it from all the places where it is applied.
> 
> It's a change in the behaviour in that the current behaviour is to
> have the empty ACL act as if it was "deny any any", and block the
> matching even if there is another ACL after it - but on the other hand
> this would take both viewpoints in mind...
I think this approach would still leave the system in an inconsistent state: an
interface is basically assigned an ACL which does not exist in the system.
Also, the risk I see is if I later on create an ACL with the previously used
index then an interface would see that ACL being applied automatically (since
it's referenced). However, I may not want to have that ACL assigned to that
particular interface. Correct?

I think that the "deletion" of an ACL could see one of the two behaviours below:
1) the deletion of an ACL should be DENIED if that ACL is assigned to any
interface (probably the easier and safer approach);
2) the deletion of an ACL should see a CASCADING effect onto the interfaces
which would be "cleaned up" of any references to that ACL;

I think (1) is a very good way of solving the initial problem since it works
nicely if you manage VPP directly (e.g. via command-line) and if you use a
controller. In the latter, the controller can react on the "error" returned by
the acl_del API because that ACL is assigned somewhere.


Cheers,
Marco

> 
> What do you think ?
> 
> --a
> 
> On 6/9/17, Andrew   Yourtchenko <ayour...@gmail.com> wrote:
> > 
> > Assuming the only change is to effectively have
> > "unbind_acl_from_everywhere; delete_acl" instead of "delete_acl",
> > maybe it would be best to tackle that post-17.07 with a separate API
> > message acl_del_and_unbind or similar ?
> > 
> > I feel a beet wary of adding more hidden state (even though the
> > reflected sessions table does provide already plenty of it :)
> > 
> > --a
> > 
> > On 6/9/17, Luke, Chris <chris_l...@comcast.com> wrote:
> > > 
> > > Would it make sense to have a flag on the interface (or globally), set
> > > when
> > > applying the ACL, that indicates the desired behavior when the ACL is
> > > empty
> > > or non-existent? At the moment to me it seems logical that this is the
> > > same
> > > behavior as when matching falls off the end of the ACL.
> > > 
> > > Chris.
> > > 
> > > > 
> > > > -Original Message-
> > > > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io]
> > > > On
> > > > Behalf Of Andrew ?? Yourtchenko
> > > > Sent: Friday, June 9, 2017 7:53
> > > > To: Marco Varlese <marco.varl...@suse.com>
> > > > Cc: vpp-dev@lists.fd.io
> > > > Subject: Re: [vpp-dev] Bind / Unbind of ACL
> > > > 
> > > > Hi Marco,
> > > > 
> > > > Yes, this works as expected, assuming after deletion *all* the traffic
> > > > is
> > > > denied, rather than just the SSH traffic.
> > > > 
> > > > If you apply to an interface the ACL# that does not exist, that is the
> > > > same as if
> > > > there was an ACL with just the "deny all" semantics, to avoid the
> > > > perception
> > > > that a given policy is enforced when it isn't - so I erred on the side
> > > > of
> > > > caution.
> > > > 
> > > > The way to remove the ACL: you would ensure the ACL is not applied to
> > > > the
> > > > interface(s) first, then remove the ACL (or replace it with a different
> > > > policy in-
> > > > place).
> > > > 
> > > > Alternatively, you can just replace the existing ACL in-place with
> > > > "permit
> > > > any"
> > > > for IPv4 and IPv6 - this way you explicitly state that there is a policy
> > > > to permit
> > > > all the traffic.
> > > > 
> > > > I've been bitten myself and seen several times in m

[vpp-dev] Troubles with multiple-threads

[Marco Varlese]

Hi,

I am seeing repeatedly issues when configuring VPP with worker threads.

My platform is a multi-socket one (NUMA) so I want to PIN the VPP threads where
my NIC card naturally belongs too (Node 3, first core is #48).

The problem I see is:
Anytime I enable the worker-threads VPP core-dumps while the traffic flows
through it (I'm running iperf3). On the other hand, it works just fine when
executed in single-thread (just the main thread).
In order to clear the air, I decided to also try without the NIC (thinking of
some issues with the PMD) and took the intra-vm scenario. Also in this case, VPP
core-dumps when executing in multi-threads mode. 

Below, you can find the configuration I am using. Any ideas would be much
appreciated.

===

unix {
  interactive
  nodaemon
  log /tmp/vpp.log
  full-coredump
}

api-trace {
  on
}

api-segment {
  gid vpp
}

cpu {
        main-core 0
        skip-cores 47
        workers 2
}


Regards,
Marco

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Bind / Unbind of ACL

[Marco Varlese]

On Fri, 2017-06-09 at 14:27 +0200, Andrew   Yourtchenko wrote:
> Hi Marco,
> 
> On 6/9/17, Marco Varlese <marco.varl...@suse.com> wrote:
> > 
> > Hi Andrew,
> > 
> > On Fri, 2017-06-09 at 13:53 +0200, Andrew   Yourtchenko wrote:
> > > 
> > > Hi Marco,
> > > 
> > > Yes, this works as expected, assuming after deletion *all* the traffic
> > > is denied, rather than just the SSH traffic.
> > > 
> > > If you apply to an interface the ACL# that does not exist, that is the
> > > same as if there was an ACL with just the "deny all" semantics, to
> > > avoid the perception that a given policy is enforced when it isn't -
> > > so I erred on the side of caution.
> > > 
> > > The way to remove the ACL: you would ensure the ACL is not applied to
> > > the interface(s) first, then remove the ACL (or replace it with a
> > > different policy in-place).
> > Ok, which function would allow me to unset the ACL from an interface?
> > I see on the documentation that 'acl_interface_add_del' is marked as "not
> > recommended" hence I wonder whether it will soon be marked as deprecated
> > and
> > eventually removed.
> 
> I encourage the users to use the acl_interface_set_acl_list mostly
> because it has a clearer (IMHO) semantics - removing all the ACLs
> means simply setting the empty list for in+out...
> 
> As for the deprecation - I think it will be a while, if at all. And of
> course if the users say "no, we find it useful and we need it", then
> it won't be deprecated at all :-)
> 
> > 
> > 
> > > 
> > > 
> > > Alternatively, you can just replace the existing ACL in-place with
> > > "permit any" for IPv4 and IPv6 - this way you explicitly state that
> > > there is a policy to permit all the traffic.
> > > 
> > > I've been bitten myself and seen several times in my career when an
> > > applied but non-existent ACL caused problems later on, in the worst
> > > possible moment. The current behaviour IMHO makes the config
> > > discrepancy clear - what do you think ?
> > In the past, when I had to work on ACL implementation, I approached the
> > solution
> > differently: an ACL (whether deny or permit) which is referenced (e.g.
> > applied
> > to one or multiple interfaces) if deleted would see a cascading effect
> > (please,
> > allow me the expression) of that deletion onto any interface which was
> > referencing it.
> > 
> > The "problem" I see - with the current approach - is that once an ACL is
> > deleted
> > it's much harder to understand / debug why a given flow is either permitted
> > or
> > not (depending on the action of the ACL). If you have hundreds or thousands
> > of
> > ACL/rules then things get complicated very quickly.
> > Instead, by applying the "cascading" effect hence freeing the interfaces
> > from
> > the previous behaviour, things would have a 1:1 mapping between what you see
> > in
> > configuration (acl_dump) with the flows you see on the network.
> 
> True, this is also a valid approach, feel free to submit a gerrit
> doing this. :-)
> 
Well, I can obviously code it but I won't code something which was discarded at
design time or won't ever be accepted.
If you feel it is a better approach then the current one then I will spend time
on it...

> I will also add you to a draft of my work-in-progress quicker lookup
> so you can see how it all interacts (and indeed will be happy to hear
> your feedback on that one too!)
> 
> I think the definition of policy and its application from the control
> plane standpoint  in this day  should be automated - so then the
> control plane would have to do this housekeeping already anyway
> internally, thus unapplying the ACL is just (in my understanding) just
> a single call. But I can see the benefits of the automatic cleanup
> too, so I am happy with either way. (especially since this does not
> break the things for the clients that do the unapply already).
> 
> --a
> 
> > 
> > 
> > > 
> > > 
> > > --a
> > Cheers,
> > Marco
> > 
> > > 
> > > 
> > > On 6/9/17, Marco Varlese <marco.varl...@suse.com> wrote:
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > I am trying the ACL functionality and I found a "strange" behaviour.
> > > > 
> > > > The steps I follow to use an ACL are:
> > > > * I create

Re: [vpp-dev] Bind / Unbind of ACL

[Marco Varlese]

Hi Andrew,

On Fri, 2017-06-09 at 13:53 +0200, Andrew   Yourtchenko wrote:
> Hi Marco,
> 
> Yes, this works as expected, assuming after deletion *all* the traffic
> is denied, rather than just the SSH traffic.
> 
> If you apply to an interface the ACL# that does not exist, that is the
> same as if there was an ACL with just the "deny all" semantics, to
> avoid the perception that a given policy is enforced when it isn't -
> so I erred on the side of caution.
> 
> The way to remove the ACL: you would ensure the ACL is not applied to
> the interface(s) first, then remove the ACL (or replace it with a
> different policy in-place).
Ok, which function would allow me to unset the ACL from an interface?
I see on the documentation that 'acl_interface_add_del' is marked as "not
recommended" hence I wonder whether it will soon be marked as deprecated and
eventually removed.

> 
> Alternatively, you can just replace the existing ACL in-place with
> "permit any" for IPv4 and IPv6 - this way you explicitly state that
> there is a policy to permit all the traffic.
> 
> I've been bitten myself and seen several times in my career when an
> applied but non-existent ACL caused problems later on, in the worst
> possible moment. The current behaviour IMHO makes the config
> discrepancy clear - what do you think ?
In the past, when I had to work on ACL implementation, I approached the solution
differently: an ACL (whether deny or permit) which is referenced (e.g. applied
to one or multiple interfaces) if deleted would see a cascading effect (please,
allow me the expression) of that deletion onto any interface which was
referencing it. 

The "problem" I see - with the current approach - is that once an ACL is deleted
it's much harder to understand / debug why a given flow is either permitted or
not (depending on the action of the ACL). If you have hundreds or thousands of
ACL/rules then things get complicated very quickly.
Instead, by applying the "cascading" effect hence freeing the interfaces from
the previous behaviour, things would have a 1:1 mapping between what you see in
configuration (acl_dump) with the flows you see on the network.

> 
> --a
Cheers,
Marco

> 
> On 6/9/17, Marco Varlese <marco.varl...@suse.com> wrote:
> > 
> > Hi,
> > 
> > I am trying the ACL functionality and I found a "strange" behaviour.
> > 
> > The steps I follow to use an ACL are:
> > * I create an ACL to deny SSH traffic between VMs (via the 'acl_add_replace'
> > function)
> > * Set that ACL to the interfaces involved (via the
> > 'acl_interface_set_acl_list'
> > function)
> > 
> > After performing the above steps the traffic was correctly being blocked.
> > 
> > However, when I decided to enable the SSH traffic again, I simply deleted
> > the
> > ACL (via the 'acl_del' function) with the consequence though that the
> > traffic
> > was still being denied.
> > 
> > Is this behaviour correct?
> > If so what would be the right way to unset hence disable a given ACL from an
> > interface (or multiple)?
> > 
> > 
> > Thanks,
> > Marco
> > 
> > ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Bind / Unbind of ACL

[Marco Varlese]

Hi,

I am trying the ACL functionality and I found a "strange" behaviour.

The steps I follow to use an ACL are:
* I create an ACL to deny SSH traffic between VMs (via the 'acl_add_replace'
function)
* Set that ACL to the interfaces involved (via the 'acl_interface_set_acl_list'
function)

After performing the above steps the traffic was correctly being blocked.

However, when I decided to enable the SSH traffic again, I simply deleted the
ACL (via the 'acl_del' function) with the consequence though that the traffic
was still being denied.

Is this behaviour correct? 
If so what would be the right way to unset hence disable a given ACL from an
interface (or multiple)?


Thanks,
Marco

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Problem with ACL plugin

[Marco Varlese]

I managed to solve this by adding running VAT as follow:

# vpp_api_test plugin_path /usr/lib64/vpp_api_test_plugins 


Cheers,
Marco

On Thu, 2017-06-08 at 13:51 +0200, Marco Varlese wrote:
> Hi,
> 
> I'm trying to use the ACL plugin but I am encountering some difficulties.
> 
> I start the VPP daemon and the output shows that the ACL plugin should be
> loaded
> correctly:
> # vpp -c /etc/vpp/startup.conf
> vlib_plugin_early_init:356: plugin path /usr/lib64/vpp_plugins
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit
> (DPDK))
> load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing
> for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment
> on
> IPv4 Infrastructure (RFC5969))
> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface
> (experimetal))
> load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address
> Translation)
> 
> However, when I use the VAT CLI to invoke any of the ACL plugin function I get
> an error back:
> # vpp_api_test 
> vat# 
> vat# acl_plugin_get_version
> 'acl_plugin_get_version': function not found
> vat# acl_add_replace
> 'acl_add_replace': function not found
> 
> Is it possible that I am missing something or that I haven't built the code
> correctly for this functionality?
> 
> 
> Thanks,
> Marco
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Problem with ACL plugin

[Marco Varlese]

Hi,

I'm trying to use the ACL plugin but I am encountering some difficulties.

I start the VPP daemon and the output shows that the ACL plugin should be loaded
correctly:
# vpp -c /etc/vpp/startup.conf
vlib_plugin_early_init:356: plugin path /usr/lib64/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit
(DPDK))
load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator addressing
for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment on
IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface
(experimetal))
load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address Translation)

However, when I use the VAT CLI to invoke any of the ACL plugin function I get
an error back:
# vpp_api_test 
vat# 
vat# acl_plugin_get_version
'acl_plugin_get_version': function not found
vat# acl_add_replace
'acl_add_replace': function not found

Is it possible that I am missing something or that I haven't built the code
correctly for this functionality?


Thanks,
Marco

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] GCC7 to build VPP

[Marco Varlese]

I actually submitted a fix for this to gerrit.
It should keep gcc5/6 happy and work with gcc7 too.


On Wed, 2017-05-31 at 11:45 +0200, Marco Varlese wrote:
> Hi all,
> 
> Is anybody using GCC7 to build the VPP source code? 
> 
> I'm seeing this:
> 
> [  297s] /home/abuild/rpmbuild/BUILD/vpp-17.07/build-
> data/../src/vnet/policer/xlate.c: In function
> 'sse2_pol_convert_hw_to_cfg_params':
> [  297s] /home/abuild/rpmbuild/BUILD/vpp-17.07/build-
> data/../src/vnet/policer/xlate.c:1319:27: error: '<<' in boolean context, did
> you mean '<' ? [-Werror=int-in-bool-context]
> [  297s]!(hw->peak_rate_man << hw->rate_exp) && !(hw-
> > 
> > extd_bkt_limit_man))
> [  297s] ~~~^~~~
> [  297s] cc1: all warnings being treated as errors
> [  297s] make[4]: *** [Makefile:5926: vnet/policer/xlate.lo] Error 1
> 
> 
> I can confirm that everything builds just fine using GCC6.
> 
> 
> Thanks,
> Marco
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] GCC7 to build VPP

[Marco Varlese]

Hi all,

Is anybody using GCC7 to build the VPP source code? 

I'm seeing this:

[  297s] /home/abuild/rpmbuild/BUILD/vpp-17.07/build-
data/../src/vnet/policer/xlate.c: In function
'sse2_pol_convert_hw_to_cfg_params':
[  297s] /home/abuild/rpmbuild/BUILD/vpp-17.07/build-
data/../src/vnet/policer/xlate.c:1319:27: error: '<<' in boolean context, did
you mean '<' ? [-Werror=int-in-bool-context]
[  297s]!(hw->peak_rate_man << hw->rate_exp) && !(hw-
>extd_bkt_limit_man))
[  297s] ~~~^~~~
[  297s] cc1: all warnings being treated as errors
[  297s] make[4]: *** [Makefile:5926: vnet/policer/xlate.lo] Error 1


I can confirm that everything builds just fine using GCC6.


Thanks,
Marco

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [csit-dev] Cryptodev "issue"

[Marco Varlese]

On Tue, 2017-05-30 at 04:32 +, Peter Mikus -X (pmikus - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Hello,
> 
> In CSIT we did not observe booting timeouts but in fact our timeout values are
> not that tight.
Ok, would it be possible to share which timeout value do you guys use?

My previous timeout was set to 30 secs (and worked perfectly), now is set to 300
(it didn't work either with 60 or 180)...


Cheers,
Marco

> 
> Peter Mikus
> Engineer - Software
> Cisco Systems Limited
> 
> -Original Message-
> From: csit-dev-boun...@lists.fd.io [mailto:csit-dev-boun...@lists.fd.io] On
> Behalf Of Sergio Gonzalez Monroy
> Sent: Monday, May 29, 2017 5:21 PM
> To: Marco Varlese <marco.varl...@suse.com>; vpp-dev@lists.fd.io; csit-dev@list
> s.fd.io
> Subject: Re: [csit-dev] [vpp-dev] Cryptodev "issue"
> 
> On 29/05/2017 15:54, Marco Varlese wrote:
> > 
> > On Mon, 2017-05-29 at 15:35 +0100, Sergio Gonzalez Monroy wrote:
> > > 
> > > Hi,
> > > 
> > > I have not seen that behavior before.
> > > 
> > > The dpdk_crypto_sw is only for enabling SW crypto, the default is to 
> > > support just HW crypto devices.
> > > 
> > > I cannot think of a reason why you would see that behavior.
> > > Basically we just check if we found enough DPDK/Cryptodev HW crypto 
> > > devices for the number of workers configured.
> > > How have you pin point the wait/stall to the Cryptodev initialization?
> > I haven't spent much time on it however this wasn't happening on the 
> > previous release (17.02) I used for my VSPerf environment. I then 
> > noticed this new "message" and thought to raise the question here.
> > 
> > If you do not see the issue and believe that cannot cause this 
> > bootstrap problem then it must be something else. I will dig further 
> > but my environment hasn't changed beside the new VPP version.
> 
> +csit-dev
> 
> CSIT tests have been running with this change and I do not think they have
> seen the issue either.
> 
> Have you not changed anything on your setup/startup.conf? ie. number of
> hugepages
> 
> Thanks,
> Sergio
> 
> > 
> > > 
> > > Thanks,
> > > Sergio
> > > 
> > > On 29/05/2017 15:27, Marco Varlese wrote:
> > > > 
> > > > Hi all,
> > > > 
> > > > I pulled the latest code from master branch last week and I'm seeing 
> > > > something new and related (possibly) to the Cryptodev support in 
> > > > VPP/DPDK.
> > > > 
> > > > The issue is that it now takes much longer for VPP to initialize...
> > > > eventually
> > > > printing out the message:
> > > > "not enough Cryptodevs, default to OpenSSL IPsec"
> > > > 
> > > > I'm building the code - as before - by:
> > > > > 
> > > > > make bootstrap
> > > > > make build-release
> > > > which produced a config file with the dpdk-crypto-sw disabled (see
> > > > below).
> > > > [   45s] with:
> > > > [   45s]   dpdk_crypto_sw  no
> > > > 
> > > > I wonder if anybody is experiencing the same behaviour (I found it 
> > > > out thanks to VSPerf which was going in timeout because of VPP)?
> > > > 
> > > > Is this something which we can disable in VPP (although from the 
> > > > configure it should already be disabled)? It looks strange to me 
> > > > that although the feature is disabled, the code is still looking for 
> > > > crypto-devs via the DPDK infrastructure.
> > > > 
> > > > Any thoughts?
> > > > 
> > > > 
> > > > Regards,
> > > > Marco
> > > > 
> > > > ___
> > > > vpp-dev mailing list
> > > > vpp-dev@lists.fd.io
> > > > https://lists.fd.io/mailman/listinfo/vpp-dev
> > > 
> > > 
> 
> ___
> csit-dev mailing list
> csit-...@lists.fd.io
> https://lists.fd.io/mailman/listinfo/csit-dev
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Cryptodev "issue"

[Marco Varlese]

On Mon, 2017-05-29 at 16:20 +0100, Sergio Gonzalez Monroy wrote:
> On 29/05/2017 15:54, Marco Varlese wrote:
> > 
> > On Mon, 2017-05-29 at 15:35 +0100, Sergio Gonzalez Monroy wrote:
> > > 
> > > Hi,
> > > 
> > > I have not seen that behavior before.
> > > 
> > > The dpdk_crypto_sw is only for enabling SW crypto, the default is to
> > > support just HW crypto devices.
> > > 
> > > I cannot think of a reason why you would see that behavior.
> > > Basically we just check if we found enough DPDK/Cryptodev HW crypto
> > > devices for the number of workers configured.
> > > How have you pin point the wait/stall to the Cryptodev initialization?
> > I haven't spent much time on it however this wasn't happening on the
> > previous
> > release (17.02) I used for my VSPerf environment. I then noticed this new
> > "message" and thought to raise the question here.
> > 
> > If you do not see the issue and believe that cannot cause this bootstrap
> > problem
> > then it must be something else. I will dig further but my environment hasn't
> > changed beside the new VPP version.
> 
> +csit-dev
> 
> CSIT tests have been running with this change and I do not think they 
> have seen the issue either.
> 
> Have you not changed anything on your setup/startup.conf? ie. number of 
> hugepages
No. As I said in my previous email, my setup has not changed beside the newer
VPP version.

> 
> Thanks,
> Sergio
> 
> > 
> > > 
> > > Thanks,
> > > Sergio
> > > 
> > > On 29/05/2017 15:27, Marco Varlese wrote:
> > > > 
> > > > Hi all,
> > > > 
> > > > I pulled the latest code from master branch last week and I'm seeing
> > > > something
> > > > new and related (possibly) to the Cryptodev support in VPP/DPDK.
> > > > 
> > > > The issue is that it now takes much longer for VPP to initialize...
> > > > eventually
> > > > printing out the message:
> > > > "not enough Cryptodevs, default to OpenSSL IPsec"
> > > > 
> > > > I'm building the code - as before - by:
> > > > > 
> > > > > make bootstrap
> > > > > make build-release
> > > > which produced a config file with the dpdk-crypto-sw disabled (see
> > > > below).
> > > > [   45s] with:
> > > > [   45s]   dpdk_crypto_sw  no
> > > > 
> > > > I wonder if anybody is experiencing the same behaviour (I found it out
> > > > thanks to
> > > > VSPerf which was going in timeout because of VPP)?
> > > > 
> > > > Is this something which we can disable in VPP (although from the
> > > > configure
> > > > it
> > > > should already be disabled)? It looks strange to me that although the
> > > > feature is
> > > > disabled, the code is still looking for crypto-devs via the DPDK
> > > > infrastructure.
> > > > 
> > > > Any thoughts?
> > > > 
> > > > 
> > > > Regards,
> > > > Marco
> > > > 
> > > > ___
> > > > vpp-dev mailing list
> > > > vpp-dev@lists.fd.io
> > > > https://lists.fd.io/mailman/listinfo/vpp-dev
> > > 
> > > 
> 
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Cryptodev "issue"

[Marco Varlese]

Hi all,

I pulled the latest code from master branch last week and I'm seeing something
new and related (possibly) to the Cryptodev support in VPP/DPDK.

The issue is that it now takes much longer for VPP to initialize... eventually
printing out the message:
"not enough Cryptodevs, default to OpenSSL IPsec"

I'm building the code - as before - by:
> make bootstrap
> make build-release

which produced a config file with the dpdk-crypto-sw disabled (see below).
[   45s] with:
[   45s]   dpdk_crypto_sw  no

I wonder if anybody is experiencing the same behaviour (I found it out thanks to
VSPerf which was going in timeout because of VPP)? 

Is this something which we can disable in VPP (although from the configure it
should already be disabled)? It looks strange to me that although the feature is
disabled, the code is still looking for crypto-devs via the DPDK
infrastructure. 

Any thoughts?


Regards,
Marco

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707 master

[Marco Varlese]

You say the ports are "down"... not sure how to interpret that but it might mean
that are still being binded to the kernel drivers.

Did you try and see if those ports are still binded with the Linux kernel
drivers? What is "dpdk-devbind.py --status" reporting?

What driver are you using in startup.conf to be used with DPDK? (vfio-pci? uio-
pci-generic? igb_uio?). Can you make sure the respective driver is loaded on the
system?

You can unbind the ports from the kernel drivers via
dpdk-devbind.py --unbind :82:00.0 (where :82:00.0 is the PCI address
representing your port on your system)


- Marco

On Tue, 2017-05-23 at 12:19 +, Michal Cmarada -X (mcmarada - PANTHEON
TECHNOLOGIES at Cisco) wrote:
> Yes it shoud be enabled because I see "DPDK drivers found no ports..." in
> output from "vpp unix interactive" command:
> 
> [root@overcloud-novacompute-1 ~]# vpp unix interactive
> vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
> load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
> load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit
> (DPDK))
> load_one_plugin:184: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
> load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
> load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
> addressing for IPv6)
> load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
> load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid Deployment
> on IPv4 Infrastructure (RFC5969))
> load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory Interface
> (experimetal))
> load_one_plugin:184: Loaded plugin: snat_plugin.so (Network Address
> Translation)
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/acl_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/flowperpkt_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_trace_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/lb_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/snat_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/udp_ping_test_plugin.so
> load_one_plugin:63: Loaded plugin:
> /usr/lib/vpp_api_test_plugins/vxlan_gpe_ioam_export_test_plugin.so
> EAL: No free hugepages reported in hugepages-1048576kB
> EAL: VFIO support initialized
> DPDK physical memory layout:
> Segment 0: phys:0x1840, len:247463936, virt:0x7f9d81a0, socket_id:0,
> hugepage_sz:2097152, nchannel:0, nrank:0
> Segment 1: phys:0x31c0, len:20971520, virt:0x7f9d5b00, socket_id:0,
> hugepage_sz:2097152, nchannel:0, nrank:0
> Segment 2: phys:0x2d4480, len:2097152, virt:0x7f9b1be0, socket_id:1,
> hugepage_sz:2097152, nchannel:0, nrank:0
> Segment 3: phys:0x2d44c0, len:266338304, virt:0x7f98ec40, socket_id:1,
> hugepage_sz:2097152, nchannel:0, nrank:0
> 0: dpdk_ipsec_process:239: not enough Cryptodevs, default to OpenSSL IPsec
> 0: dpdk_lib_init:182: DPDK drivers found no ports...
> 0: svm_client_scan_this_region_nolock:1140: /vpe-api: cleanup ghost pid 5540
> 0: svm_client_scan_this_region_nolock:1140: /global_vm: cleanup ghost pid 5540
> _____   _  ___
>  __/ __/ _ \  (_)__| | / / _ \/ _ \
>  _/ _// // / / / _ \   | |/ / ___/ ___/
>  /_/ /(_)_/\___/   |___/_/  /_/
> 
> vpp# sh int
>   Name   Idx   State  Counter  Cou
> nt
> local00down
> 
> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> Behalf Of Kinsella, Ray
> Sent: Tuesday, May 23, 2017 2:16 PM
> To: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] VPP has no interfaces after update from 1704 to 1707
> master
> 
> Is the dpdk plugin enabled?
> 
> Ray K
> 
> On 23/05/2017 13:01, Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at
> Cisco) wrote:
> > 
> > Hi VPP devs,
> > 
> > 
> > 
> > I tried to update VPP to master version from stable 1704 on Centos. In
> > 1704 everything was working. Now in 1707 master VPP does not pick the 
> > physical interfaces. I tried to change the drivers and I whitelisted 
> > the interfaces in startup.conf for vpp. All the interfaces are down so 
> > VPP should pick them. But nothing 

Re: [vpp-dev] VPP unable to link external .so libs

[Marco Varlese]

Hi Devendra,

Did you try to look at src/plugins/dpdk.am ?


Cheers,
Marco

On Thu, 2017-05-18 at 15:42 +0530, devendra rawat wrote:
> Hi,
> 
> I am trying to run VPP on an arm64 processor. I am using DPDK v16.11.
> > My board is having a non-pci ethernet interface I have added a PMD for that 
> > in
DPDK.
> >  This PMD makes calls to an external library libxal which is platform
specific. All DPDK
> apps. including testpmd work fine.
> 
> Using this DPDK I built vpp on my board:
> 
> > > # make V=1 build-release vpp_uses_external_dpdk=yes
vpp_dpdk_inc_dir=/root/work/vector/dpdk-v16.11/_install/include/dpdk
vpp_dpdk_lib_dir=/root/work/vector/dpdk-v16.11/_install/lib
> 
> My VPP startup.conf file:
> 
> unix {
>   interactive
>   log /tmp/vpp.log
>   cli-listen localhost:5002
> }
> api-trace {
>   on
> }
> dpdk {
>   coremask 0xff
>   vdev uio_xal_enet0 #dpdk vdev device
> }
> 
> On staring VPP:
> 
> > root@ubuntu:~/work/vector/vpp# ./build-root/build-vpp-native/vpp/bin/vpp -c
../startup.conf 
> vlib_plugin_early_init:360: plugin path /usr/lib/vpp_plugins
> load_one_plugin:188: Loaded plugin: acl_plugin.so (Access Control Lists)
> > load_one_plugin:188: Loaded plugin: dpdk_plugin.so (Data Plane Development 
> > Kit
(DPDK))
> load_one_plugin:188: Loaded plugin: flowperpkt_plugin.so (Flow per Packet)
> > load_one_plugin:188: Loaded plugin: ila_plugin.so (Identifier-locator
addressing for IPv6)
> load_one_plugin:188: Loaded plugin: ioam_plugin.so (Inbound OAM)
> load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:188: Loaded plugin: lb_plugin.so (Load Balancer)
> > load_one_plugin:188: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid 
> > Deployment
on IPv4 Infrastructure (RFC5969))
> > load_one_plugin:188: Loaded plugin: memif_plugin.so (Packet Memory Interface
(experimetal))
> > load_one_plugin:188: Loaded plugin: snat_plugin.so (Network Address
Translation)
> EAL: Detected 8 lcore(s)
> EAL: Probing VFIO support...
> EAL: VFIO support initialized
> > EAL: cannot open /proc/self/numa_maps, consider that all memory is in
socket_id 0
> > /root/work/vector/vpp/build-root/build-vpp-native/vpp/bin/.libs/lt-vpp: 
> > symbol
lookup error: /usr/lib/vpp_plugins/dpdk_plugin.so: undefined symbol: xal_init
> -
> 
> > linking to libxal is not done, hence it is unable to find xal_init() 
> > function
def. This is visible from the ldd command output 
> for dpdk_plugin.so and lt-vpp. setting LD_LIBRARY_PATH is not helping too.
> 
> root@ubuntu:~/work/vector/vpp# ldd /usr/lib/vpp_plugins/dpdk_plugin.so
>     linux-vdso.so.1 =>  (0x007fb19b1000)
>     libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x007fb1366000)
>     libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x007fb1353000)
>     libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x007fb120b000)
>     /lib/ld-linux-aarch64.so.1 (0x0055586e)
> 
> > root@ubuntu:~/work/vector/vpp# ldd 
> > /root/work/vector/vpp/build-root/build-vpp-
native/vpp/bin/.libs/lt-vpp
>     linux-vdso.so.1 =>  (0x007f79f4b000)
> >     libvlibapi.so.0 => /root/work/vector/vpp/build-root/build-vpp-
native/vpp/.libs/libvlibapi.so.0 (0x007f79f3)
> >     libvlibmemory.so.0 => /root/work/vector/vpp/build-root/build-vpp-
native/vpp/.libs/libvlibmemory.so.0 (0x007f79f11000)
> >     libvlib.so.0 => /root/work/vector/vpp/build-root/build-vpp-
native/vpp/.libs/libvlib.so.0 (0x007f79eb6000)
> >     libvnet.so.0 => /root/work/vector/vpp/build-root/build-vpp-
native/vpp/.libs/libvnet.so.0 (0x007f79bbc000)
> >     libsvm.so.0 => /root/work/vector/vpp/build-root/build-vpp-
native/vpp/.libs/libsvm.so.0 (0x007f79ba2000)
> >     libsvmdb.so.0 => /root/work/vector/vpp/build-root/build-vpp-
native/vpp/.libs/libsvmdb.so.0 (0x007f79b8d000)
> >     libvppinfra.so.0 => /root/work/vector/vpp/build-root/build-vpp-
native/vpp/.libs/libvppinfra.so.0 (0x007f79b2f000)
> >     libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0
(0x007f79af2000)
>     libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x007f79adf000)
>     libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x007f79998000)
>     /lib/ld-linux-aarch64.so.1 (0x00556db75000)
> >     libcrypto.so.1.0.0 => /lib/aarch64-linux-gnu/libcrypto.so.1.0.0
(0x007f797f3000)
>     librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x007f797dc000)
> 
> > How can I link external libs to dpdk_plugin.so ? libxal is placed in
/usr/local/lib.
> 
> Thanks,
> Devendra
> 
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] CSIT borked on master

[Marco Varlese]

Hi Damjan,
As per your input I waited for your patch to be merged and then rebased mine.
However, the vpp-csit-verify-virl-master still fails... 

Shall I try to "recheck" again?


Thanks,
Marco

On Mon, 2017-05-15 at 11:39 +, Damjan Marion (damarion) wrote:
> 
> 
> 
> 
> 
> > “recheck" will not be enough. All patches must be rebased so they pick up my
fix...
> 
> 
> 
> 
> > > > On 15 May 2017, at 13:38, Neale Ranns (nranns) <nra...@cisco.com> wrote:
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > Hi Marco,
> > 
> > 
> >  
> > 
> > 
> > I’ll restart the jobs once we’ve got them passing again.
> > 
> > 
> >  
> > 
> > 
> > > > For your reference, you can do it manually by typing ‘recheck’ as a code
review comment in gerrit.
> > 
> > 
> >  
> > 
> > 
> > regards,
> > 
> > 
> > neale
> > 
> > 
> >  
> > 
> > > 
> > > 
> > > > > > From: Marco Varlese <marco.varl...@suse.com>
> > > 
> > > Date: Monday, 15 May 2017 at 12:17
> > > 
> > > > > > > > > > > > To: "Damjan Marion (damarion)" <damar...@cisco.com>, 
> > > > > > > > > > > > "Neale Ranns
(nranns)" <nra...@cisco.com>
> > > 
> > > > > > > > > Cc: "csit-...@lists.fd.io" <csit-...@lists.fd.io>,
> > > > > >  vpp-dev <vpp-dev@lists.fd.io>
> > > 
> > > Subject: Re: [vpp-dev] CSIT borked on master
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Hi Damjan,
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > > > Once you're patch is merged, is it possible to kick off the builds 
> > > > > > which
currently are all marked as Verified-1 so to have a clean state on them?
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > If I could do that manually I would do it at least for mine.
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Thanks,
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Marco
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On Mon, 2017-05-15 at 10:54 +, Damjan Marion (damarion) wrote:
> > > 
> > > 
> > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > This issue is caused by bug in DPDK 17.05 caused by following commit:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > http://dpdk.org/browse/dpdk/commit/?id=ee1843b
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > > > > It happens only with old QEMU emulation (I repro it with 
> > > > > > > > “pc-1.0”) which
VIRL uses.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Fix (revert) is in gerrit:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > https://gerrit.fd.io/r/#/c/6690/
> > > > 
> > > > 
> > > > 
> > > &g

Re: [vpp-dev] CSIT borked on master

[Marco Varlese]

Hi Damjan,

Once you're patch is merged, is it possible to kick off the builds which
currently are all marked as Verified-1 so to have a clean state on them?

If I could do that manually I would do it at least for mine.


Thanks,
Marco

On Mon, 2017-05-15 at 10:54 +, Damjan Marion (damarion) wrote:
> 
> 
> 
> 
> 
> This issue is caused by bug in DPDK 17.05 caused by following commit:
> 
> 
> 
> 
> 
> http://dpdk.org/browse/dpdk/commit/?id=ee1843b
> 
> 
> 
> 
> 
> > It happens only with old QEMU emulation (I repro it with “pc-1.0”) which 
> > VIRL
uses.
> 
> 
> 
> 
> 
> Fix (revert) is in gerrit:
> 
> 
> 
> 
> 
> https://gerrit.fd.io/r/#/c/6690/
> 
> 
> 
> 
> 
> Regards,
> 
> 
> 
> 
> 
> Damjan
> 
> 
> 
> 
> 
> 
> 
> 
> > > > On 13 May 2017, at 20:34, Neale Ranns (nranns)  wrote:
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > Hi Chris,
> > 
> > 
> >  
> > 
> > 
> > Yes, every CSIT job on master is borked.
> > 
> > 
> > > > > > I think I’ve narrowed this down to all VAT sw_interface_dump 
> > > > > > returning
bogus/garbage MAC addresses. No Idea why, can’t repro yet. I’ve a
speculative DPDK 17.05 bump backout job in the queue, for
> >  purposes of elimination.
> > 
> > 
> >  
> > 
> > 
> > Regards,
> > 
> > 
> > /neale
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> > > 
> > > 
> > > > > > From: "Luke, Chris" 
> > > 
> > > Date: Saturday, 13 May 2017 at 19:04
> > > 
> > > > > > > > > To: "Neale Ranns (nranns)" , 
> > > > > > > > > "yug...@telincn.com"
> > > > > > > > >  , vpp-dev 
> > > 
> > > > > > Subject: RE: [vpp-dev] Segmentation fault in recursivly lookuping 
> > > > > > fib
entry.
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > CSIT seems to be barfing on every job at the moment :(
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > > > > > > From: vpp-dev-boun...@lists.fd.io 
> > > > > > > > > [mailto:vpp-dev-boun...@lists.fd.io] On
> > >  Behalf Of Neale Ranns (nranns)
> > > 
> > > Sent: Saturday, May 13, 2017 11:20
> > > 
> > > > > > > > > To: yug...@telincn.com; vpp-dev 
> > > 
> > > > > > Subject: Re: [vpp-dev] Segmentation fault in recursivly lookuping 
> > > > > > fib
entry.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > >  
> > > 
> > > 
> > > https://gerrit.fd.io/r/#/c/6674/
> > > 
> > > 
> > >  
> > > 
> > > 
> > > /neale
> > > 
> > > 
> > >  
> > > 
> > > > 
> > > > 
> > > > > > > > From: "yug...@telincn.com"
> > > > > > > >  
> > > > 
> > > > Date: Saturday, 13 May 2017 at 14:24
> > > > 
> > > > > > > > > > > > To: "Neale Ranns (nranns)" , vpp-dev 
> > > > > > > > > > > > 
> > > > 
> > > > > > > > Subject: Re: Re: [vpp-dev] Segmentation fault in recursivly 
> > > > > > > > lookuping
fib entry.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Hi neale,
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Could you leave me a msg then?
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Thanks,
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Ewan
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > yug...@telincn.com
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > From: Neale
> > > > >  Ranns (nranns)
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Date: 2017-05-13 20:33
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > > > > > To: yug...@telincn.com; vpp-dev
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > > > > > Subject: Re: [vpp-dev] Segmentation fault in recursivly 
> > > > > > > > > > lookuping fib
entry.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Hi Ewan,
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > That’s a bug. I’ll fix it ASAP.
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > 
> > > > > neale
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > > > > > > From: 
> > > > > > > > > > > > > > > > > >  on behalf of "yug...@telincn.com" 
> > > > > > > > > > > > > > > > > > 
> > > > > > 
> > > > > > Date: Saturday, 13 May 2017 at 03:24
> > > > > > 
> > > > > > > > > > > > To: vpp-dev 
> > > > > > 
> > > > > > > > > > > > Subject: [vpp-dev] Segmentation fault in recursivly 
> > > > > > > > > > > > lookuping fib
entry.
> > > > > > 

Re: [vpp-dev] Add support to CI for openSUSE

[Marco Varlese]

Hi Vanessa,

Did you get any chance to look into this? 
I tried to login onto the ticketing system but I still get the unauthorized
error.

If you cannot add me to the system, I am more than happy to have any updates via
email.


Thanks,
Marco

On Wed, 2017-05-03 at 04:21 -0700, Ed Warnicke wrote:
> > Vanessa,     Could you get Marco access to the ticketing system and where do
we stand on getting the OpenSuse VM?
> 
> Ed
> 
> 
> > On Wed, May 3, 2017 at 1:35 AM, Marco Varlese <marco.varl...@suse.com> 
> > wrote:
> > 
> >   
> >   Hi Vanessa and Ed,
> > > > > > Since I do not have permissions to see the status of the ticket (I 
> > > > > > get
Unauthorized when accessing the link below after being correctly logged in),
would you be so kind to provide some updates?
> > 
> > Thanks and regards,
> > Marco
> > 
> > On Mon, 2017-04-10 at 10:12 -0500, Vanessa Valderrama wrote:
> > > Ed,
> > > I've opened RT
> > > > > >   
> > > > > > https://rt-sso.linuxfoundation.org/Ticket/Display.html?id=39618 to
> > >   track this issue.  This is a project so I'll need to review with
> > >   Andy before I can provide an ETA.
> > > Thank you,
> > > 
> > > Vanessa
> > > 
> > > 
> > > 
> > > On 04/10/2017 09:49 AM, Ed Warnicke
> > >   wrote:
> > > 
> > > 
> > > 
> > > >   Looping in a few more folks to help get this moving
> > > > at various levels.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Vanessa/Andy,
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > What do we need to do to get OpenSuse Jenkins Minions
> > > >   going?
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Ed
> > > > 
> > > >   
> > > > 
> > > >   
> > > > 
> > > > On Mon, Apr 10, 2017 at 2:38 AM, Marco
> > > > > > > >   Varlese <marco.varl...@suse.com>
> > > >   wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > 
> > > > > I would like to ask if it is possible to add openSUSE
> > > > > distribution in the CI for
> > > > > 
> > > > > FD.IO/VPP.
> > > > > 
> > > > > We are currently packaging it and I think it would be
> > > > > extremely beneficial to
> > > > > 
> > > > > have the CI running on our distribution too.
> > > > > 
> > > > > 
> > > > > 
> > > > > Is it at all possible? If so would you please advise what
> > > > > would you require on
> > > > > 
> > > > > my side to make this happen so that I can assist?
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Thanks and regards,
> > > > > 
> > > > > Marco
> > > > > 
> > > > >   
> > > > 
> > > > 
> > > > 
> > > > 
> > > >   
> > > > 
> > > 
> > > 
> > >   
> > > 
> > 
> > 
> > 
> 
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Add support to CI for openSUSE

[Marco Varlese]

Hi Vanessa and Ed,
Since I do not have permissions to see the status of the ticket (I get
Unauthorized when accessing the link below after being correctly logged in),
would you be so kind to provide some updates?

Thanks and regards,
Marco

On Mon, 2017-04-10 at 10:12 -0500, Vanessa Valderrama wrote:
> 
> Ed,
> I've opened RT
> >   https://rt-sso.linuxfoundation.org/Ticket/Display.html?id=39618 to
>   track this issue.  This is a project so I'll need to review with
>   Andy before I can provide an ETA.
> Thank you,
> 
> Vanessa
> 
> 
> 
> On 04/10/2017 09:49 AM, Ed Warnicke
>   wrote:
> 
> 
> 
> >   Looping in a few more folks to help get this moving
> > at various levels.
> > 
> > 
> > 
> > 
> > Vanessa/Andy,
> > 
> > 
> > 
> > 
> > 
> > What do we need to do to get OpenSuse Jenkins Minions
> >   going?
> > 
> >     
> > 
> > 
> > 
> > Ed
> > 
> >   
> > 
> >   
> > 
> > On Mon, Apr 10, 2017 at 2:38 AM, Marco
> > > >   Varlese <marco.varl...@suse.com>
> >   wrote:
> > 
> > > Hi,
> > > 
> > > 
> > > I would like to ask if it is possible to add openSUSE
> > > distribution in the CI for
> > > 
> > > FD.IO/VPP.
> > > 
> > > We are currently packaging it and I think it would be
> > > extremely beneficial to
> > > 
> > > have the CI running on our distribution too.
> > > 
> > > 
> > > 
> > > Is it at all possible? If so would you please advise what
> > > would you require on
> > > 
> > > my side to make this happen so that I can assist?
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Thanks and regards,
> > > 
> > > Marco
> > > 
> > >   
> > 
> > 
> > 
> > 
> >   
> > 
> 
> 
>   
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Build failure with latest VPP

[Marco Varlese]

On Fri, 2017-04-14 at 11:19 +, Damjan Marion (damarion) wrote:
> Marco,
> 
> If you want to do downstream packaging and link against shared dpdk, you can 
> do it by compiling directly from autotools project. Basically:
> 
> cd src/
> autoreconf -fis
> export CFLAGS=….
> ./configure —flags
> make
> make install
> 
> Please note that we are intentionally linking against static DPDK libs as want
> to have flexibility
> of adding additional patches to dpdk build. Currently we have bunch of patcher
> related to Mellanox ConnectX-5 
> which are not available in latest dpdk release.
I understand why you use the internal DPDK version. 
However, I am hopeful (for the future) that cross-collaboration with the DPDK
project can avoid the need of keep doing this (for all the good reason of having
a common up-stream project with all the goodies in it rather than some sort of
"fork" in a consumer project).

> 
> May I ask what are your distro guidance when it comes to optimization of the
> code for specific 
> microarchitectures? Do you need to support all x86_64 systems or just few
> latest generations?
We support DPDK since version 2.2 (roughly mid-2015) so I would say any
processor which is not older than 2 years...

> 
> How do you compile DPDK?
I think the easiest for me here is to post here the link to our .spec file used
to generate the package we ship...
https://build.opensuse.org/package/view_file/network/dpdk/dpdk.spec?expand=1
You should be able to access it; in case you can't, please, let me know so I can
send it to you...

I'm going to try your suggested steps and will let you know how it goes.

> 
> Thanks,
> 
> Damjan
Thanks,
Marco


> 
> 
> > 
> > On 12 Apr 2017, at 11:33, Marco Varlese <marco.varl...@suse.com> wrote:
> > 
> > BTW, in case you're wondering which commands I am using to build:
> > 
> > > 
> > > make bootstrap
> > > make build (using build-release produces the same issue)
> > 
> > 
> > Regards,
> > Marco
> > 
> > On Tue, 2017-04-11 at 09:27 +0200, Marco Varlese wrote:
> > > 
> > > Hi,
> > > 
> > > I am facing a build issue with the latest VPP and not sure if others have
> > > seen
> > > the same? (I'm copying/pasting the errors below)
> > > 
> > > It appears to be broken for both "shared dpdk" and using the "in-repo"
> > > dpdk
> > > source code. Both compilation mode worked just fine for me using VPP 17.01
> > > so
> > > not sure if I have to change anything in the .mk files or build the code
> > > differently...
> > > 
> > > I have to say that since I am very interested in consuming the VPP code
> > > downstream the "shared mode" compilation option is much more valuable to
> > > me...
> > > 
> > > Any help would be much appreciated.
> > > 
> > > 
> > > When building in shared mode for dpdk I get the following error:
> > > 
> > > t -f 'vpp/app/version.c' || echo '/home/abuild/rpmbuild/BUILD/vpp/build-
> > > data/../src/'`vpp/app/version.c
> > > [  415s] /home/abuild/rpmbuild/BUILD/vpp/build-
> > > data/../src/vpp/vnet/main.c:21:29: fatal error: vpp/app/version.h: No such
> > > file
> > > or directory
> > > [  415s]  #include 
> > > [  415s]  ^
> > > [  415s] compilation terminated.
> > > [  415s] make[4]: *** [Makefile:5872: vpp/vnet/bin_vpp-main.o] Error 1
> > > [  415s] make[4]: *** Waiting for unfinished jobs
> > > [  415s] /home/abuild/rpmbuild/BUILD/vpp/build-
> > > data/../src/vpp/app/version.c:17:29: fatal error: vpp/app/version.h: No
> > > such
> > > file or directory
> > > [  415s]  #include 
> > > [  415s]  ^
> > > [  415s] compilation terminated.
> > > [  415s] make[4]: *** [Makefile:5900: vpp/app/bin_vpp-version.o] Error 1
> > > [  415s] mv -f vpp/app/.deps/bin_vpp-vpe_cli.Tpo vpp/app/.deps/bin_vpp-
> > > vpe_cli.Po
> > > [  416s] mv -f vpp-api/pneum/.deps/libpneum_la-pneum.Tpo vpp-
> > > api/pneum/.deps/libpneum_la-pneum.Plo
> > > [  425s] make[4]: Leaving directory
> > > '/home/abuild/rpmbuild/BUILD/vpp/build-
> > > root/build-vpp-native/vpp'
> > > [  425s] make[3]: *** [Makefile:6764: all-recursive] Error 1
> > > [  425s] make[3]: Leaving directory
> > > '/home/abuild/rpmbuild/BUILD/vpp/build-
> > > root/build-vpp-native/vpp'
> > > [  425s] make[2]: *** [Makefile:3426: all] Error 2
> > > [  42

Re: [vpp-dev] Build failure with latest VPP

[Marco Varlese]

Hi Burt,

The problem is that the steps I follow today are the exact same I followed 2
months ago (with previous release - as mentioned in my earlier email) but today
that doesn't work anymore... install-dep does not work on SUSE but that is not
"the issue" since packages can be installed manually and the issue I encounter
is not related to missing libs/executables/headers from system file-system
(version.h is a file created - or should be - by the build-system within the vpp
repo). Having said that the server and the OS I'm using is the same as 2 months
ago...

Separate, I found somebody else (I think it was Thomas Herbert) reporting a
similar issue with "version.h" (not found) when building the code downstream
from tarball... so apparently I may not be the only one facing some build issue?

With regards to the support for openSUSE: that request came from me... and I
spoke to Ed f2f about it last week.


- Marco

On Wed, 2017-04-12 at 13:53 -0400, Burt Silverman wrote:
> > > > > What about make install-dep prior to make bootstrap and maybe 
> > > > > that will
not work on SUSE... you would have to look at the top level Makefile for
RPM_DEPENDS and make certain they are pulled in, manually if needed. I think I
saw a request for SUSE recently -- maybe Ed Warnicke knows if there is a plan
to support it.
> 
> Burt
> 
> > On Wed, Apr 12, 2017 at 5:33 AM, Marco Varlese <marco.varl...@suse.com> 
> > wrote:
> > BTW, in case you're wondering which commands I am using to build:
> > 
> > 
> > > make bootstrap
> > 
> > > make build (using build-release produces the same issue)
> > 
> > 
> > 
> > 
> > 
> > Regards,
> > 
> > Marco
> > 
> > 
> > 
> > On Tue, 2017-04-11 at 09:27 +0200, Marco Varlese wrote:
> > 
> > > Hi,
> > 
> > >
> > 
> > > > > I am facing a build issue with the latest VPP and not sure if others 
> > > > > have
seen
> > 
> > > the same? (I'm copying/pasting the errors below)
> > 
> > >
> > 
> > > > > It appears to be broken for both "shared dpdk" and using the "in-repo"
dpdk
> > 
> > > > > source code. Both compilation mode worked just fine for me using VPP 
> > > > > 17.01
so
> > 
> > > not sure if I have to change anything in the .mk files or build the code
> > 
> > > differently...
> > 
> > >
> > 
> > > I have to say that since I am very interested in consuming the VPP code
> > 
> > > > > downstream the "shared mode" compilation option is much more valuable 
> > > > > to
me...
> > 
> > >
> > 
> > > Any help would be much appreciated.
> > 
> > >
> > 
> > >
> > 
> > > When building in shared mode for dpdk I get the following error:
> > 
> > >
> > 
> > > t -f 'vpp/app/version.c' || echo '/home/abuild/rpmbuild/BUILD/vpp/build-
> > 
> > > data/../src/'`vpp/app/version.c
> > 
> > > [  415s] /home/abuild/rpmbuild/BUILD/vpp/build-
> > 
> > > data/../src/vpp/vnet/main.c:21:29: fatal error: vpp/app/version.h: No such
> > 
> > > file
> > 
> > > or directory
> > 
> > > [  415s]  #include 
> > 
> > > [  415s]  ^
> > 
> > > [  415s] compilation terminated.
> > 
> > > [  415s] make[4]: *** [Makefile:5872: vpp/vnet/bin_vpp-main.o] Error 1
> > 
> > > [  415s] make[4]: *** Waiting for unfinished jobs
> > 
> > > [  415s] /home/abuild/rpmbuild/BUILD/vpp/build-
> > 
> > > > > data/../src/vpp/app/version.c:17:29: fatal error: vpp/app/version.h: 
> > > > > No
such
> > 
> > > file or directory
> > 
> > > [  415s]  #include 
> > 
> > > [  415s]  ^
> > 
> > > [  415s] compilation terminated.
> > 
> > > [  415s] make[4]: *** [Makefile:5900: vpp/app/bin_vpp-version.o] Error 1
> > 
> > > [  415s] mv -f vpp/app/.deps/bin_vpp-vpe_cli.Tpo vpp/app/.deps/bin_vpp-
> > 
> > > vpe_cli.Po
> > 
> > > [  416s] mv -f vpp-api/pneum/.deps/libpneum_la-pneum.Tpo vpp-
> > 
> > > api/pneum/.deps/libpneum_la-pneum.Plo
> > 
> > > > > [  425s] make[4]: Leaving directory
'/home/abuild/rpmbuild/BUILD/vpp/build-
> > 
> > > root/build-vpp-native/vpp'
> > 
> > > [  425s] make[3]: *** [Makefile:6764: all-recursive] Error 

[vpp-dev] Build failure with latest VPP

[Marco Varlese]

Hi,

I am facing a build issue with the latest VPP and not sure if others have seen
the same? (I'm copying/pasting the errors below)

It appears to be broken for both "shared dpdk" and using the "in-repo" dpdk
source code. Both compilation mode worked just fine for me using VPP 17.01 so
not sure if I have to change anything in the .mk files or build the code
differently...

I have to say that since I am very interested in consuming the VPP code
downstream the "shared mode" compilation option is much more valuable to me...

Any help would be much appreciated.


When building in shared mode for dpdk I get the following error:

t -f 'vpp/app/version.c' || echo '/home/abuild/rpmbuild/BUILD/vpp/build-
data/../src/'`vpp/app/version.c
[  415s] /home/abuild/rpmbuild/BUILD/vpp/build-
data/../src/vpp/vnet/main.c:21:29: fatal error: vpp/app/version.h: No such file
or directory
[  415s]  #include 
[  415s]  ^
[  415s] compilation terminated.
[  415s] make[4]: *** [Makefile:5872: vpp/vnet/bin_vpp-main.o] Error 1
[  415s] make[4]: *** Waiting for unfinished jobs
[  415s] /home/abuild/rpmbuild/BUILD/vpp/build-
data/../src/vpp/app/version.c:17:29: fatal error: vpp/app/version.h: No such
file or directory
[  415s]  #include 
[  415s]  ^
[  415s] compilation terminated.
[  415s] make[4]: *** [Makefile:5900: vpp/app/bin_vpp-version.o] Error 1
[  415s] mv -f vpp/app/.deps/bin_vpp-vpe_cli.Tpo vpp/app/.deps/bin_vpp-
vpe_cli.Po
[  416s] mv -f vpp-api/pneum/.deps/libpneum_la-pneum.Tpo vpp-
api/pneum/.deps/libpneum_la-pneum.Plo
[  425s] make[4]: Leaving directory '/home/abuild/rpmbuild/BUILD/vpp/build-
root/build-vpp-native/vpp'
[  425s] make[3]: *** [Makefile:6764: all-recursive] Error 1
[  425s] make[3]: Leaving directory '/home/abuild/rpmbuild/BUILD/vpp/build-
root/build-vpp-native/vpp'
[  425s] make[2]: *** [Makefile:3426: all] Error 2
[  425s] make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/vpp/build-
root/build-vpp-native/vpp'
[  425s] make[1]: *** [Makefile:699: vpp-build] Error 2
[  425s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/vpp/build-root'
[  425s] make: *** [Makefile:213: build-release] Error 2
[  425s] error: Bad exit status from /var/tmp/rpm-tmp.t3xVux (%build)
[  425s] 
[  425s] 
[  425s] RPM build errors:
[  425s] Bad exit status from /var/tmp/rpm-tmp.t3xVux (%build)
[  425s] 
[  425s] linux-yk3w.suse failed "build vpp.spec" at Tue Apr 11 07:19:21 UTC
2017.
[  425s] 


On the other hand, when building the code using the in-repo dpdk source code I
get the following one:

  CC test.o
/usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/libmvec_nonshared.a(svml_finite_alias.oS): relocation R_X86_64_PC32
against undefined symbol `_ZGVbN2v_log@@GLIBC_2.22' can not be used when making
a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/ld: final
link failed: Bad value
collect2: error: ld returned 1 exit status
/home/mvarlese/repos/vpp/build-root/build-vpp-native/dpdk/dpdk-
17.02/mk/rte.app.mk:235: recipe for target 'cmdline_test' failed
make[9]: *** [cmdline_test] Error 1
/home/mvarlese/repos/vpp/build-root/build-vpp-native/dpdk/dpdk-
17.02/mk/rte.subdir.mk:61: recipe for target 'cmdline_test' failed
make[8]: *** [cmdline_test] Error 2
make[8]: *** Waiting for unfinished jobs
  CC resource.o


Thanks and regards,
Marco

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Add support to CI for openSUSE

[Marco Varlese]

Hi,

I would like to ask if it is possible to add openSUSE distribution in the CI for
FD.IO/VPP.
We are currently packaging it and I think it would be extremely beneficial to
have the CI running on our distribution too.

Is it at all possible? If so would you please advise what would you require on
my side to make this happen so that I can assist?


Thanks and regards,
Marco
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Build VPP for thunderx platform

[Marco Varlese]

On Wed, 2017-01-04 at 12:03 -0500, Burt Silverman wrote:
> Marco, it looks like the vpp.mk and vpp_lite.mk make an effort to distinguish
> between x86_64 and NOT x86_64, but do not go beyond that. I agree it sounds
> like that could be fleshed out for thunderx, so you can get some optimal
> values for march, mtune, and whatever.
It does look like something is broken though. As you correctly said, the vpp.mk
does distinguish at least between x86 and non-x86 architectures; however, if I
take a clean snapshot from git and use the following commands:
1) make PLATFORM=vpp bootstrap
2) make PLATFORM=vpp build
I get the following error:
make[10]: *** [/root/repos/vpp/build-root/build-vpp_debug-native/dpdk/dpdk
-16.11/mk/internal/rte.compile-pre.mk:140: eal_pci_uio.o] Error 1 

make[10]: *** Waiting for unfinished jobs 
In file included from /root/repos/vpp/build-root/install-vpp_debug
-native/dpdk/include/rte_memcpy.h:46:0, 
 from /root/repos/vpp/build-root/build-vpp_debug
-native/dpdk/dpdk-16.11/lib/librte_eal/common/rte_malloc.c:40:
/root/repos/vpp/build-root/install-vpp_debug
-native/dpdk/include/rte_vect.h:69:23: fatal error: x86intrin.h: No such file or
directory
#include 


It looks like vpp.mk does not correctly waterfall the architecture (i.e.
aarch64) to the local/internal DPDK build system since it tries to build for a
x86 target...
- Marco
> On Wed, Jan 4, 2017 at 11:46 AM, Christophe FONTAINE > 
> <christophe.fonta...@qosmos.com>>  wrote:
> > Hi Marco,
> > 

> > 
> > I'm a bit surprised you had a lot of issues compiling directly on the 
> > board: I don't have a ThunderX board to test, but I just built vpp on a 
> > nxp1043, which is an armv8 platform.
> > 
> > And just like you, no cross compilation.
> > 
> > So, I have 2 suggestions:
> > 
> > - try build first with PLATFORM=vpp_lite : with this, we can first check if 
> > everything but dpdk is building correctly.
> > 
> > FYI, I did not try to build the packages as I'm on a stripped Ubuntu rootfs 
> > on this platform
> > 
> > - Them switch to VPP, but using an already installed DPDK: within vpp.mk, 
> > you have the possibility to override the default values (ie external dpdk)
> > 

> > 
> > Christophe
> > 

> > 
> > > -Original Message-
> > 
> > > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> > 
> > > Behalf Of Marco Varlese
> > 
> > > Sent: mercredi 4 janvier 2017 17:36
> > 
> > > To: Rami Rosen <roszenr...@gmail.com>; Burt Silverman
> > 
> > > <bur...@gmail.com>
> > 
> > > Cc: vpp-dev <vpp-dev@lists.fd.io>
> > 
> > > Subject: Re: [vpp-dev] Build VPP for thunderx platform
> > 
> > >
> > 
> > > Mine was a typo mistake
> > 
> > > My command has PLATFORM=thunder
> > 
> > >
> > 
> > > As mentioned previously, I'm on the actual platform so no need to use 
> > > cross -
> > 
> > > compiler...
> > 
> > >
> > 
> > >
> > 
> > > On Wed, 2017-01-04 at 17:15 +0200, Rami Rosen wrote:
> > 
> > > > Hi Marco,
> > 
> > > > Indeed it should be PLATFORM=thunder, according to my understanding.
> > 
> > > > Second, you also need to have the thunderx cross compiler installed on
> > 
> > > > your build machine (aarch64-thunderx-linux-gnu-> > gcc), so it seems to
> > 
> > > > me. It is a Cavium tool, part of their thunderx-tools, not sure where
> > 
> > > > it can be downloaded from.
> > 
> > > >
> > 
> > > >
> > 
> > > > Regards,
> > 
> > > > Rami Rosen
> > 
> > > >
> > 
> > > >
> > 
> > > > On 4 January 2017 at 16:04, Burt Silverman <bur...@gmail.com> wrote:
> > 
> > > > > Can't say for sure, but perhaps PLATFORM=thunder is the answer.
> > 
> > > > >
> > 
> > > > > On Wed, Jan 4, 2017 at 8:33 AM, Marco Varlese
> > 
> > > > > <marco.varl...@suse.com>
> > 
> > > > > wrote:
> > 
> > > > > >
> > 
> > > > > > Hi,
> > 
> > > > > >
> > 
> > > > > > I'm trying to build VPP for the ThunderX platform.
> > 
> > > > > > I've a platform in the lab so I've no need for cross-compiling, etc.
> > 
> > > > > >
> > 
> > > > > > However, if I run t

Re: [vpp-dev] Build VPP for thunderx platform

[Marco Varlese]

On Wed, 2017-01-04 at 16:46 +, Christophe FONTAINE wrote:
> Hi Marco,
> 
> I'm a bit surprised you had a lot of issues compiling directly on the board: I
> don't have a ThunderX board to test, but I just built vpp on a nxp1043, which
> is an armv8 platform.
> And just like you, no cross compilation.
> So, I have 2 suggestions:
> - try build first with PLATFORM=vpp_lite : with this, we can first check if
> everything but dpdk is building correctly.
I can successfully build DPDK... downloaded 16.11 from dpdk.org and built it
with no issues on my thunderx machine...
Also, what I tried to point out earlier is:
1) PLATFORM=vpp (is accepted by the build system)
2) PLATFORM=vpp_lite (is accepted by the buid system)
3) PLATFORM=arm32 (is accepted by the build system)
4) PLATFORM = thunder (is unrecognised by the build system as a valid platform)
> FYI, I did not try to build the packages as I'm on a stripped Ubuntu rootfs on
> this platform
> - Them switch to VPP, but using an already installed DPDK: within vpp.mk, you
> have the possibility to override the default values (ie external dpdk)
I always use the external dpdk option from vpp.mk...
> 
> Christophe
> 
> > -Original Message-
> > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> > Behalf Of Marco Varlese
> > Sent: mercredi 4 janvier 2017 17:36
> > To: Rami Rosen <roszenr...@gmail.com>; Burt Silverman
> > <bur...@gmail.com>
> > Cc: vpp-dev <vpp-dev@lists.fd.io>
> > Subject: Re: [vpp-dev] Build VPP for thunderx platform
> > 
> > Mine was a typo mistake
> > My command has PLATFORM=thunder
> > 
> > As mentioned previously, I'm on the actual platform so no need to use cross 
> > -
> > compiler...
> > 
> > 
> > On Wed, 2017-01-04 at 17:15 +0200, Rami Rosen wrote:
> > > Hi Marco,
> > > Indeed it should be PLATFORM=thunder, according to my understanding.
> > > Second, you also need to have the thunderx cross compiler installed on
> > > your build machine (aarch64-thunderx-linux-gnu-gcc), so it seems to
> > > me. It is a Cavium tool, part of their thunderx-tools, not sure where
> > > it can be downloaded from.
> > > 
> > > 
> > > Regards,
> > > Rami Rosen
> > > 
> > > 
> > > On 4 January 2017 at 16:04, Burt Silverman <bur...@gmail.com> wrote:
> > > > Can't say for sure, but perhaps PLATFORM=thunder is the answer.
> > > > 
> > > > On Wed, Jan 4, 2017 at 8:33 AM, Marco Varlese
> > > > <marco.varl...@suse.com>
> > > > wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I'm trying to build VPP for the ThunderX platform.
> > > > > I've a platform in the lab so I've no need for cross-compiling, etc.
> > > > > 
> > > > > However, if I run the default "make bootstrap && make build" the
> > > > > vpp.mk file is used and eventually the makefile builds for
> > > > > generic-native platform (resulting in a ton of include errors...)
> > > > > 
> > > > > If I instead try to use the command "make PLATFORM=thunderx build"
> > > > > then I get the "Unkown platform" error although I can see the file
> > > > > thunder.mk in /build -data/platforms
> > > > > 
> > > > > I can't find any documentation/guidelines to build specifially for
> > > > > the Thunderx platform so I would be grateful if anybody could
> > > > > point me to the right direction/documentation.
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > Marco
> > > > > ___
> > > > > vpp-dev mailing list
> > > > > vpp-dev@lists.fd.io
> > > > > https://lists.fd.io/mailman/listinfo/vpp-dev
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > vpp-dev mailing list
> > > > vpp-dev@lists.fd.io
> > > > https://lists.fd.io/mailman/listinfo/vpp-dev
> > > 
> > ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io
> > https://lists.fd.io/mailman/listinfo/vpp-dev
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake, please let us know by reply and then delete it from your system; you
> should not copy it or disclose its contents to anyone. All messages sent to
> and from Enea may be monitored to ensure compliance with internal policies and
> to protect our business. Emails are not secure and cannot be guaranteed to be
> error free as they can be intercepted, amended, lost or destroyed, or contain
> viruses. The sender therefore does not accept liability for any errors or
> omissions in the contents of this message, which arise as a result of email
> transmission. Anyone who communicates with us by email accepts these risks.
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev