Re: [vpp-dev] VPP Custom SELinux Policy - New Dependencies

[Billy McFall]

The VPP Custom SELinux Policy has been merged to master. This is a heads up
for CentOS, Fedora and RHEL, this patch introduces new package
dependencies: selinux-policy selinux-policy-devel

Depending on your system and what is currently installed, you may need to
re-run `make install-dep` to pickup these new packages.

If anyone runs into any issues on CentOS/Fedora/RHEL, drop me an email and
I'll take a look.

Thanks,
Billy McFall


On Mon, Jan 15, 2018 at 6:09 PM, Billy McFall <bmcf...@redhat.com> wrote:

> I have pushed an initial pass at a VPP Custom SELinux Policy to Gerrit for
> review. Prior to the start this venture, I knew zero about SELinux, so
> please let me know if you see something you don't like. That being said,
> the internal Red Hat SELinux team has reviewed and blessed it. If you have
> any interest, see: https://gerrit.fd.io/r/#/c/10111/
>
> As far as I know, Debian tends not to use SELinux in favor of AppArmor. So
> the SELinux Policy is currently only implemented for RPM packages,
> specifically, Fedora, CentOS and RHEL. I have been in touch with Marco
> regarding Suse and we will follow up with that separately.
>
> I used the following document to keep track of notes as I implemented the
> VPP Custom SELinux Policy: VPP_SELinux_FilesAndLabels
> <https://docs.google.com/document/d/1OEAodU3lY3z0qLrxOmdvwqdfZCWbzLs-6Z77CeWEHE0/edit?usp=sharing>
> Primarily, the document lists:
> * Questions raised during implementation (most of which have been answered)
> * List of files added to the system by VPP and the SELinux label they were
> assigned, if any.
> * List of files remaining on a system once VPP was uninstalled.
> * Test Cases
>
>
> Below are some questions about file and socket names and directories. Most
> of these are file names and directories input by the user, so it is a
> question of how we document it. Some of these only matter if SELinux is
> enabled, so I don't want to force a change for the non-SELinux users.
> However, I would like a discussion around the directories files are place
> in.
>
> * Scripts
> The Wiki (https://wiki.fd.io/view/VPP/Command-line_Interface_(CLI)_Gu
> ide#command_scripts) shows examples of running command scripts out of
> /tmp (i.e. - vppctl exec /tmp/script). With SELinux enabled, user created
> scripts out of '/tmp' and '/home//' will not execute due to
> permissions. I did all my testing by moving my scripts to
> '/usr/share/vpp/scripts/'. The other option is to create a '/tmp/vpp/'
> directory which I can add a rule to label as 'vpp_tmp_t' (which I have not
> done yet, but can do easily). Any thoughts or preferences?
>
> * vHost Sockets
> There is a lot of discussion online about location and permissions around
> vhost sockets, primarily with regards to OVS. In server mode (from vSwitch
> perspective), OVS settled on '/var/run/openvswitch/', and in Client Mode
> (again from vSwitch perspective),
> OpenStack wants '/var/lib/vhost_sockets/'. FYI - OVS is deprecating Server
> mode going forward.
>
> The Wiki and CLI Doxygen documentation for VPP show examples of vhost
> sockets being created in '/tmp/'. I would like to update the documentation
> to point to '/var/run/vpp/' for vhost sockets. I still have work to do on
> permissions to get something like '/var/lib/vhost_sockets/' in client mode
> working properly. Once again, this is purely what the documentation shows,
> code doesn't care about location if SELinux is disabled.
>
> * Log Files:
> Just curious if there was any reason the default location for the log file
> was '/tmp/vpp.log' and not something like '/var/log/vpp/vpp.log'?
>
> As is, '/tmp/vpp.log' will get labeled with 'vpp_tmp_t' and works fine.
> However, I also created 'vpp_log_t' along with a '/var/log/vpp/' directory
> if we want to use it. By moving it, it can get labeled with vpp_var_run_t
> and the correct permissions for things logrotate are set properly.
>
> Thanks,
> Billy McFall
>
> --
> *Billy McFall*
> Networking Group
> CTO Office
> *Red Hat*
>



-- 
*Billy McFall*
Networking Group
CTO Office
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] What RPM contains vpp debug symbols?

[Billy McFall]

'make pkg-rpm' is currently not generating an RPM with debug symbols. There
is a bug in  rpmbuild for packages with short names (i.e. - vpp) that was
not allowing RPMs to be built upstream in CentOS and RHEL. The work around
is to add a -0 to the package name to make it long enough. Much later after
this change was merged, it was discovered that the debug RPM was not being
built.

Thomas Herbert is tracking the issue. rpmbuild has been fixed in Fedora but
that fix has not been pulled into CentOS or RHEL. Not sure when it will
make it. Thomas can give more details, I am just regurgitating what he
previously reported to me.

Billy McFall


On Thu, Jan 25, 2018 at 6:57 PM, Dave Wallace <dwallac...@gmail.com> wrote:

> Does anyone know what RPM contains debug symbols?
>
> Back in VPP 17.07 there used to be an RPM package called
> vpp-debuginfo-*.x86_64.rpm, but that package is no longer installed on
> nexus.fd.io starting with release 17.10
>
> https://nexus.fd.io/content/repositories/fd.io.stable.
> 1707.centos7/io/fd/vpp/vpp-debuginfo/17.07.01-release.
> x86_64/vpp-debuginfo-17.07.01-release.x86_64.rpm
>
> Thanks,
> -daw-
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>



-- 
*Billy McFall*
Networking Group
CTO Office
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VPP Custom SELinux Policy

[Billy McFall]

I have pushed an initial pass at a VPP Custom SELinux Policy to Gerrit for
review. Prior to the start this venture, I knew zero about SELinux, so
please let me know if you see something you don't like. That being said,
the internal Red Hat SELinux team has reviewed and blessed it. If you have
any interest, see: https://gerrit.fd.io/r/#/c/10111/

As far as I know, Debian tends not to use SELinux in favor of AppArmor. So
the SELinux Policy is currently only implemented for RPM packages,
specifically, Fedora, CentOS and RHEL. I have been in touch with Marco
regarding Suse and we will follow up with that separately.

I used the following document to keep track of notes as I implemented the
VPP Custom SELinux Policy: VPP_SELinux_FilesAndLabels
<https://docs.google.com/document/d/1OEAodU3lY3z0qLrxOmdvwqdfZCWbzLs-6Z77CeWEHE0/edit?usp=sharing>
Primarily, the document lists:
* Questions raised during implementation (most of which have been answered)
* List of files added to the system by VPP and the SELinux label they were
assigned, if any.
* List of files remaining on a system once VPP was uninstalled.
* Test Cases


Below are some questions about file and socket names and directories. Most
of these are file names and directories input by the user, so it is a
question of how we document it. Some of these only matter if SELinux is
enabled, so I don't want to force a change for the non-SELinux users.
However, I would like a discussion around the directories files are place
in.

* Scripts
The Wiki (https://wiki.fd.io/view/VPP/Command-line_Interface_(CLI)_
Guide#command_scripts) shows examples of running command scripts out of
/tmp (i.e. - vppctl exec /tmp/script). With SELinux enabled, user created
scripts out of '/tmp' and '/home//' will not execute due to
permissions. I did all my testing by moving my scripts to
'/usr/share/vpp/scripts/'. The other option is to create a '/tmp/vpp/'
directory which I can add a rule to label as 'vpp_tmp_t' (which I have not
done yet, but can do easily). Any thoughts or preferences?

* vHost Sockets
There is a lot of discussion online about location and permissions around
vhost sockets, primarily with regards to OVS. In server mode (from vSwitch
perspective), OVS settled on '/var/run/openvswitch/', and in Client Mode
(again from vSwitch perspective),
OpenStack wants '/var/lib/vhost_sockets/'. FYI - OVS is deprecating Server
mode going forward.

The Wiki and CLI Doxygen documentation for VPP show examples of vhost
sockets being created in '/tmp/'. I would like to update the documentation
to point to '/var/run/vpp/' for vhost sockets. I still have work to do on
permissions to get something like '/var/lib/vhost_sockets/' in client mode
working properly. Once again, this is purely what the documentation shows,
code doesn't care about location if SELinux is disabled.

* Log Files:
Just curious if there was any reason the default location for the log file
was '/tmp/vpp.log' and not something like '/var/log/vpp/vpp.log'?

As is, '/tmp/vpp.log' will get labeled with 'vpp_tmp_t' and works fine.
However, I also created 'vpp_log_t' along with a '/var/log/vpp/' directory
if we want to use it. By moving it, it can get labeled with vpp_var_run_t
and the correct permissions for things logrotate are set properly.

Thanks,
Billy McFall

-- 
*Billy McFall*
Networking Group
CTO Office
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] openSUSE build fails

[Billy McFall]

On Fri, Dec 15, 2017 at 5:15 AM, Marco Varlese  wrote:

> Hi Damjan,
>
> On Fri, 2017-12-15 at 09:06 +, Damjan Marion (damarion) wrote:
>
>
>
> On 15 Dec 2017, at 08:52, 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).
>
> 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/ - 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_64 : A GNU program for formatting C code
Repo: base
:

$ sudo repoquery -i indent
Name: indent
Version : 2.2.11
Release : 13.el7
Architecture: x86_64
Size: 359131
Packager: CentOS BuildSystem 
Group   : Applications/Text
URL : http://indent.isidore-it.eu/beautify.html   <-- BUSTED LINK
Repository  : base
Summary : A GNU program for formatting C code
Source  : indent-2.2.11-13.el7.src.rpm
Description :
Indent is a GNU program for beautifying C code, so that it is easier to
read.  Indent can also convert from one C writing style to a different
one.  Indent understands correct C syntax and tries to handle incorrect
C syntax.

Install the indent package if you are developing applications in C and
you want a program to format your code.


>
>
>
>
> 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...
>
>
> We all know that we have extreme fragile system, as obviously we are not
> be able to
> fix that in almost 2 years, so as long as the system is as it increasing
> complexity doesn't help
> and just causes frustration.
>
> 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...
>
>
> Marco, decision to have verify jobs on 2 distros was made much before you
> joined the project,
> and I don't remember serious decision on that topic, it might be that at
> that time
> we were simply unexperienced, or maybe we didn't expect infra to be so
> fragile.
>
> Fact is that now we have ridiculous situation, 2 verify jobs says patch is
> OK, 3rd one says
> it is not. Which one to trust?
>
> So please don't take this personal, i know you invested time to get suse
> build working, but still
> I think it is a valid question to ask, do we really need 3 verify jobs.
> Should we have 4 tomorrow
> if somebody invest his time to do verify job on Archlinux for example?
>
> Thanks,
>
> Damjan
>
>
>
> --
>
> 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 mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Is there a planned VPP 17.10.01?

[Billy McFall]

I see a handful of merges on stable/1710 and was just looking to see if
there is a scheduled date or plan for a VPP 17.10.01 release? OR are these
merges just there in-case there is a VPP 17.10.01 release in the future?

Thanks,
Billy McFall

-- 
*Billy McFall*
Networking Group
CTO Office
*Red Hat*
___
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

[Billy McFall]

Klement,

Thank you for the path "drop python3 dependency" on master (
https://gerrit.fd.io/r/#/c/8584/), it will make ours lives downstream much
easier. I don't see the patch on stable/1710. Is there a plan to cherry
pick to 1710? (Sorry if it already there, just didn't see it.)

Thanks,
Billy McFall


On Mon, Sep 25, 2017 at 8:03 AM, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco) <ksek...@cisco.com> wrote:

> Quoting Thomas F Herbert (2017-09-25 13:31:55)
> >On 09/25/2017 05:02 AM, Marco Varlese wrote:
> >
> >  Thanks for the thorough explanation Klement!Based on that, I think (2)
> is still the better option for the current situation...
> >
> >  Tom, how would that sound to you?
> >
> >
> >  "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)" [1]<
> 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)" [2]<
> 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 [3]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.
> >
> >That's OK. You would have had to test with a system without EPEL Repo
> >enabled to discover this problem.
> >
> >I should have paid closer attention when this patch was first
> discussed in
> >May. Please add me as a reviewer for patches that have implications
> for
> >RPM packaging and requirements.
> >
> >
> >  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.
> >
> >I think this is a good interim work-around until the distros have
> Python3.
> >I can submit another patch to allow this the inclusion would be
> enabled as
> >a default but could be disabled only in downstream builds in RHEL and
> >Centos 7.
> >
> >When will we have tests in CSIT that use the C/C++ APIs in 17.10?
> >
> >Neale, are we planning to cherry-pick this patch into 17.10?
> >
> >Do we have yet tests in CSIT that use the C/C++ APIs in 17.10?
>
> Let me rephrase my words to clarify possible confusion which I see. New
> C/C++ API bindings are just a way of calling old VPP APIs in a more
> user-friendly way. They still call e.g. sw_interface_dump - there is no
> change to APIs themselves.
>
> So it's important to distinguish between API (e.g. sw_interface_dump)
> and API binding (which is a language-specific way of constructing
> sw_interface_dump message and sending it over shared memory to VPP).
>
> I don't know about CSIT, but "make test" tests use python API bindings,
> which internally uses old C API bindings (vapiclient). Unless we want
> to remove old C API, there is little motivation to rework python API
> binding as it contains more or less the same logic as the new C/C++ API
> bindings.
>
> There is one test though which doesn't - test_vapi.py, which builds its
> own test client

Re: [vpp-dev] physmem rework patch

[Billy McFall]

To test, do we need to change anything else with our setup, like remove
80-vpp.conf?

If I have HugePages_Total set to 8192 via grub, and 80-vpp.conf is set to
the default of 1024, my system should stay at 8192 (provided there is
enough free hugepages), correct?

Thanks,
Billy

On Thu, Sep 7, 2017 at 6:30 AM, Damjan Marion (damarion) <damar...@cisco.com
> wrote:

>
> Dear vpp-devers,
>
> As I mentioned on the last community call, there is patch which
> significantly changes
> the way how VPP is allocating wired memory, including the dpdk hugepages.
>
> Patch is available here and it is passing verify jobs:
>
> https://gerrit.fd.io/r/#/c/7701/
>
> With this change, VPP is able dynamically pre-allocate hugepages, if they
> are not already available.
>
> This change is affecting DPDK buffer mempools, as now they are allocated
> by VPP, and not directly by DPDK.
> I use dpdk rte_mempool_xmem_create (...) to pass allocated wired memory
> region to dpdk.
>
> Result is smaller memory footprint, mainly thanks to the better control of
> memory allocation we have.
> DPDK is still allocating 64M/socket for it’s internal data structures and
> VPP allocates 40MB/socket for
> our default number of buffers (16K). In case people want more buffers, it
> is enough to increase num_mbufs parameter
> and VPP will increase size of mempool automatically, which is significant
> improvement as currently people need to play
> with socket-mem parameter.
>
> In total, footprint is reduced from 256M/socket to 104M/socket.
>
> At the moment, code only deals with 2M pages, support for 1G pages for
> extreme VPP consumers will be added in the separate patch.
>
> I will really appreciate if people can try this patch and report
> success/failure. It important that we test it in different
> configurations before it is merged.
>
> Thanks,
>
> Damjan
>
>
>
>
>
> _______
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev




-- 
*Billy McFall*
SDN Group
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Hugepage/Memory Allocation Rework

[Billy McFall]

Damjan,

On the VPP call yesterday, you described the patch you are working on to
rework how VPP allocates and uses hugepages. Per request from Jerome
Tollet, I wrote VPP-958 <https://jira.fd.io/browse/VPP-958> to document
some issues they were seeing. I believe your patch will address this issue.
I added a comment to the JIRA. Is my comment in the JIRA accurate?

Save you from having to follow the link:

Damjan Marion is working on a patch that reworks how VPP uses memory. With
the patch, VPP will not need to allocate memory using 80-vpp.conf. Instead,
when VPP is started, it will check to insure there are enough free
hugespages for it to function. If so, it will not touch the current huge
page allocation. If not, it will attempt to allocate what it needs.

This patch also reduces the default amount of memory VPP requires. This is
a fairly big change so it will probably not be merged until after 17.10. I
believe this patch will address the concerns of this JIRA. I will update
this JIRA as progress is made.

This may not be the final patch, but here is the current work in progress:
https://gerrit.fd.io/r/#/c/7701/

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

Re: [vpp-dev] VPP Performance drop from 17.04 to 17.07

[Billy McFall]

Thanks for the update John. I'll this along to our test team. Not sure when
we can schedule a retest, but when we do, I'll provide our results.

Thanks again,
Billy

On Tue, Sep 5, 2017 at 10:10 AM, John Lo (loj) <l...@cisco.com> wrote:

> Hi Billy,
>
>
>
> I submitted fixes for VPP-963, now merged in both 17.07 and master/17.10,
> that I believe should address the NDR/PDR performance issue with the 10K
> and 1M flow cases. The regression was caused by a bug fix in the L2
> learning path to update stale time stamp and sequence number of MAC entries
> in L2FIB. Because the time stamp is in unit of  minutes, whenever the clock
> hits the minute mark, there can be a prolonged burst of MAC updates
> affecting forwarding performance with large number of MACs in L2 FIB
> needing updates. My fix would smooth out the update burst to reduce the
> impact. I believe you should now find the 17.07 or 17.10 performance for
> 10K and 1M flows slightly lower but fairly close to the level of 17.04,
> instead of somewhere between 1/3 to 1/2 to that of the 17.04 as you
> measured before.
>
>
>
> I also doubled the memory size of L2FIB table to fit 4M MACs and set the
> learn limit to 4M entries. During my test, I found L2FIB will run out of
> memory at around 2.8M MACs with the previous memory size.
>
>
>
> Regards,
>
> John
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Billy McFall
> *Sent:* Monday, August 28, 2017 12:47 PM
> *To:* Maciek Konstantynowicz (mkonstan) <mkons...@cisco.com>
> *Cc:* csit-...@lists.fd.io; vpp-dev <vpp-dev@lists.fd.io>
> *Subject:* Re: [vpp-dev] VPP Performance drop from 17.04 to 17.07
>
>
>
>
>
>
>
> On Mon, Aug 28, 2017 at 8:53 AM, Maciek Konstantynowicz (mkonstan) <
> mkons...@cisco.com> wrote:
>
> + csit-dev
>
>
>
> Billy,
>
>
>
> Per the last week CSIT project call, from CSIT perspective, we
>
> classified your reported issue as Test coverage escape.
>
>
>
> Summary
>
> ===
>
> CSIT test coverage got fixed, see more detail below. The CSIT tests
>
> uncovered regression for L2BD with MAC learning with higher total number
>
> of MACs in L2FIB, >>10k MAC, for multi-threaded configurations. Single-
>
> threaded configurations seem to be not impacted.
>
>
>
> Billy, Karl, Can you confirm this aligns with your findings?
>
>
>
> When you say "multi-threaded configuration", I assume you mean multiple
> worker threads? Karl's tests had 4 workers, one for each NIC (physical
> and vhost-user). He only tested multi-threaded, so we can not confirm that 
> single-threaded
> configurations seem to be not impacted.
>
>
>
> Our numbers are a little different from yours, but we are both seeing
> drops between releases. We had a bigger drop off with 10k flows, but seems
> to be similar with the million flow tests.
>
>
>
> I was a little disappointed the MAC limit change by John Lo on 8/23 didn't
> improve master number some.
>
>
>
> Thanks for all the hard work and adding these additional test cases.
>
>
>
> Billy
>
>
>
>
>
> More detail
>
> ===
>
> MAC scale tests have been now added L2BD and L2BD+vhost CSIT suites, as
>
> a simple extension to existing L2 testing suites. Some known issues with
>
> TG prevented CSIT to add those tests in the past, but now as TG issues
>
> have been addressed, the tests could be added swiftly. The complete list
>
> of added tests is listed in [1] - thanks to Peter Mikus for great work
>
> there!
>
>
>
> Results from running those tests multiple times within FD.io
> <http://fd.io> CSIT lab
>
> infra can be glanced over by checking dedicated test trigger commits
>
> [2][3][4], summary graphs in linked xls [5]. The results confirm there
>
> is regression in VPP l2fib code affecting all scaled up MAC tests in
>
> multi-thread configuration. Single-thread configurations seems not be
>
> impacted.
>
>
>
> The tests in commit [1] are not merged yet, as they're waiting for
>
> TG/TRex team to fix TRex issue with mis-calculating Ethernet FCS with
>
> large number of L2 MAC flows (>10k MAC flows). Issue is tracked by [6],
>
> TRex v2.29 with the fix ETA is w/e 1-Sep i.e. this week. Reported CSIT test
>
> results are using Ethernet frames with UDP headers that's masking the
>
> TRex issue.
>
>
>
> We have also vpp git bisected the problem between v17.04 (good) and
>
> v17.07 (bad) in a separate IXIA based lab in SJC, and found the culprit
>
> vpp patch [7]. Awaiting fix from vpp-dev, jira

Re: [vpp-dev] set dpdk interface placement

[Billy McFall]

The command was renamed to:
   set/show interface rx-placement

On Tue, Aug 22, 2017 at 5:39 AM, 真我风采 <1534057...@qq.com> wrote:

> there is no the commad "vppctl set dpdk interface placement" in
> version17.07, but exist in version 17.04, this command has been abrogate
> ???
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>



-- 
*Billy McFall*
SDN Group
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP Performance drop from 17.04 to 17.07

[Billy McFall]

The
issue appears to be (see number below from previous email) that a magnitude
more packets were flooded than before.

Billy


> Above are a few generic comments I can think of, without knowing much
> details about how the tests are setup and measured. Hope it can help to
> explain the different behavior observed between 1704 and 1707.
>
>
>
> Regards,
>
> John
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Billy McFall
> *Sent:* Monday, August 14, 2017 6:40 PM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] VPP Performance drop from 17.04 to 17.07
>
>
>
> In the last VPP call, I reported some internal Red Hat performance testing
> was showing a significant drop in performance between releases 17.04 to
> 17.07. This with l2-bridge testing - PVP - 0.002% Drop Rate:
>
>VPP-17.04: 256 Flow 7.8 MP/s 10k Flow 7.3 MP/s 1m Flow 5.2 MP/s
>
>VPP-17.07: 256 Flow 7.7 MP/s 10k Flow 2.7 MP/s 1m Flow 1.8 MP/s
>
>
>
> The performance team re-ran some of the tests for me with some additional
> data collected. Looks like the size of the L2 FIB table was reduced in
> 17.07. Below are the number of entries in the MAC Table after the tests are
> run:
>
>17.04:
>
>  show l2fib
>
>  408 l2fib entries
>
>17.07:
>
>  show l2fib
>
>  1067053 l2fib entries with 1048576 learned (or non-static) entries
>
>
>
> This caused more packets to be flooded (see out of 'show node counters'
> below). I looked but couldn't find anything. Is the size of the L2 FIB
> Table table configurable?
>
>
>
> Thanks,
>
> Billy McFall
>
>
>
>
>
> 17.04:
>
>
>
> show node counters
>
>CountNode  Reason
>
> :
>
>  313035313l2-inputL2 input packets
>
> 555726l2-floodL2 flood packets
>
> :
>
>  310115490l2-inputL2 input packets
>
> 824859l2-floodL2 flood packets
>
> :
>
>  313508376l2-inputL2 input packets
>
>1041961l2-floodL2 flood packets
>
> :
>
>  313691024l2-inputL2 input packets
>
> 698968l2-floodL2 flood packets
>
>
>
> 17.07:
>
>
>
> show node counters
>
>CountNode  Reason
>
> :
>
>   97810569l2-inputL2 input packets
>
>   72557612l2-floodL2 flood packets
>
> :
>
>   97830674l2-inputL2 input packets
>
>   72478802l2-floodL2 flood packets
>
> :
>
>   97714888l2-inputL2 input packets
>
>   71655987l2-floodL2 flood packets
>
> :
>
>   97710374l2-inputL2 input packets
>
>   70058006l2-floodL2 flood packets
>
>
>
>
>
> --
>
> *Billy McFall*
> SDN Group
> Office of Technology
> *Red Hat*
>



-- 
*Billy McFall*
SDN Group
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [csit-dev] about UT test framework for VPP

[Billy McFall]

FYI - I was able to run "make test" on my Fedora laptop. I noticed the
scapy wasn't installed, so I ran "pip uninstall scapy" on the CentOS server
that is having the issue. Still has the problem.


Here is the output:
(virtualenv)[bmcfall@d2fxl02 test]$ scapy
INFO: Can't import matplotlib. Won't be able to plot.
INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
Traceback (most recent call last):
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/bin/scapy",
line 25, in 
interact()
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/main.py",
line 300, in interact
scapy_builtins = __import__("all",globals(),locals(),".").__dict__
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/all.py",
line 28, in 
from scapy.route6 import *
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
line 273, in 
conf.route6 = Route6()
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
line 31, in __init__
self.resync()
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
line 44, in resync
self.routes = read_routes6()
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/arch/linux.py",
line 283, in read_routes6
cset = scapy.utils6.construct_source_candidate_set(d, dp, devaddrs,
LOOPBACK_NAME)
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
line 50, in construct_source_candidate_set
if in6_isgladdr(addr) or in6_isuladdr(addr):
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
line 708, in in6_isgladdr
return in6_isincluded(str, '2000::', 3)
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
line 651, in in6_isincluded
temp = inet_pton(socket.AF_INET6, addr)

Billy McFall


On Tue, Aug 15, 2017 at 10:02 AM, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco) <ksek...@cisco.com> wrote:

> We do not use the system-wide scapy, instead we install a specific
> version of scapy which we patch with our own stuff.
>
> Could you try "make test-shell" and run scapy from the spawned shell?
>
> Thanks,
> Klement
>
> Quoting Billy McFall (2017-08-15 14:26:33)
> >Thanks Klement,
> >Details:
> >  OS: CentOS Linux release 7.3.1611
> >  Kernel: 3.10.0-514.21.1.el7.x86_64
> >  sudo scapy
> >  INFO: Can't import python gnuplot wrapper . Won't be able to plot.
> >  INFO: Can't import PyX. Won't be able to use psdump() or pdfdump().
> >  Welcome to Scapy (2.3.1)
> >  >>>
> >Let me know if there is something else that would help.
> >Billy
> >On Tue, Aug 15, 2017 at 4:02 AM, Klement Sekera -X (ksekera - PANTHEON
> >TECHNOLOGIES at Cisco) <[1]ksek...@cisco.com> wrote:
> >
> >  Hi Billy,
> >
> >  I haven't seen this issue yet, but it looks like this is a scapy
> issue
> >  on your box. Scapy is a 3rd party library which we use in the test
> >  framework. What is the exact version of your OS etc?
> >
> >  Thanks,
> >  Klement
> >
> >  Quoting Billy McFall (2017-08-14 21:30:35)
> >  >I am trying to run "make test" on a CentOS bare metal server.
> I'm
> >  getting
> >  >"Exception: Illegal syntax for IP address". What do I need to
> >  >setup/configure on my server before running "make test"?
> >  >Thanks,
> >  >Billy McFall
> >  >$ make test V=2
> >  >make -C /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root
> >  >PLATFORM=vpp TAG=vpp vpp-install
> >  >make[1]: Entering directory
> >  >`/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root'
> >  > Arch for platform 'vpp' is native 
> >  > Finding source for dpdk 
> >  > Makefile fragment found in
> >  >
> >  /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-data/
> packages/[1][2]dpdk.mk
> >  >
> >  > Source

[vpp-dev] VPP Performance drop from 17.04 to 17.07

[Billy McFall]

In the last VPP call, I reported some internal Red Hat performance testing
was showing a significant drop in performance between releases 17.04 to
17.07. This with l2-bridge testing - PVP - 0.002% Drop Rate:
   VPP-17.04: 256 Flow 7.8 MP/s 10k Flow 7.3 MP/s 1m Flow 5.2 MP/s
   VPP-17.07: 256 Flow 7.7 MP/s 10k Flow 2.7 MP/s 1m Flow 1.8 MP/s

The performance team re-ran some of the tests for me with some additional
data collected. Looks like the size of the L2 FIB table was reduced in
17.07. Below are the number of entries in the MAC Table after the tests are
run:
   17.04:
 show l2fib
 408 l2fib entries
   17.07:
 show l2fib
 1067053 l2fib entries with 1048576 learned (or non-static) entries

This caused more packets to be flooded (see out of 'show node counters'
below). I looked but couldn't find anything. Is the size of the L2 FIB
Table table configurable?

Thanks,
Billy McFall


17.04:

show node counters
   CountNode  Reason
:
 313035313l2-inputL2 input packets
555726l2-floodL2 flood packets
:
 310115490l2-inputL2 input packets
824859l2-floodL2 flood packets
:
 313508376l2-inputL2 input packets
   1041961l2-floodL2 flood packets
:
 313691024l2-inputL2 input packets
698968l2-floodL2 flood packets

17.07:

show node counters
   CountNode  Reason
:
  97810569l2-inputL2 input packets
  72557612l2-floodL2 flood packets
:
  97830674l2-inputL2 input packets
  72478802l2-floodL2 flood packets
:
  97714888l2-inputL2 input packets
  71655987l2-floodL2 flood packets
:
  97710374l2-inputL2 input packets
  70058006l2-floodL2 flood packets


-- 
*Billy McFall*
SDN Group
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vppctl bug?

[Billy McFall]

I am seeing this same issue on stable/1707 but can't reproduce on master. I
tried to back port a couple patches from master back to stable/1707 to see
if they fixed it but haven't been able to pinpoint the fix. Does anyone
know if this was purposely fixed on master?

Billy McFall

On Thu, Jul 13, 2017 at 2:34 PM, Yichen Wang (yicwang) <yicw...@cisco.com>
wrote:

> [Resend]
>
>
>
> This is 100% reproducible, and kind of blocking our automation. Anyone
> knows the reason?
>
>
>
> Thanks very much!
>
>
>
> Regards,
>
> Yichen
>
>
>
> *From: *"Yichen Wang (yicwang)" <yicw...@cisco.com>
> *Date: *Tuesday, July 11, 2017 at 14:51
> *To: *Denis Lotarev via vpp-dev <vpp-dev@lists.fd.io>
> *Subject: *vppctl bug?
>
>
>
> Hi, VPP folks,
>
>
>
> Using a pretty new VPP 17.07-rc2 RPM:
>
> neutron_vpp_8422 [root@sjc04-pod6-compute-1 /]# vppctl show ver verbose
>
> Version:  v17.07-rc2~3-g0786710~b20
>
> Compiled by:  jenkins
>
> Compile host: centos7-basebuild-4c-4g-489
>
> Compile date: Thu Jul  6 18:21:54 UTC 2017
>
> Compile location: /w/workspace/vpp-merge-1707-centos7
>
> Compiler: GCC 4.8.5 20150623 (Red Hat 4.8.5-11)
>
> Current PID:  69
>
>
>
> When I use “telnet 0 5002” I can see all information are returned
> correctly, but with vppctl, the same CLI just like break in the middle.
> Looks like a bug in vppctl, 100% reproducible:
>
> [root@sjc04-pod6-compute-1 /]# vppctl show int rx-placement
>
> Thread 1 (vpp_wk_0
>
> [root@sjc04-pod6-compute-1 /]#
>
>
>
> Thanks very much!
>
>
>
> Regards,
>
> Yichen
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>



-- 
*Billy McFall*
SDN Group
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Weekly VPP Meeting

[Billy McFall]

I just discovered there was a VPP Meeting today. I have a conflict so I
won't be able to attend. I see I now have an agenda item, VPP -> RedHat
Release

Status Update:
* Ed W. pushed a patch (work around) into 17.07 so vppctl can run as a
non-root user. Damjan pushed the actual fix into master, but is disabled
currently. Thank you Damjan and Ed.
* Billy is working on SELinux Policy so VPP will run with SELinux enabled.
Still early stages and with minimal testing, VPP seems to work fine, only
see permission issue instantiating VMs (connecting to vHost sockets). More
testing needed.
* Thomas is working on getting CSIT running on local servers.
* Source RPM work needs to be done upstream. Need to remove GIT dependency.

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

[vpp-dev] 17.04 dot releases not pushed to Nexus

[Billy McFall]

I noticed that 17.04.1 and 17.04.2 releases were not pushed to Nexus (or
I'm looking in the wrong spot). I think they should be but was wondering if
there was a reason they weren't.

Example:

https://nexus.fd.io/content/repositories/fd.io.ubuntu.xenial.main/io/fd/vpp/vpp/
   https://nexus.fd.io/content/repositories/fd.io.centos7/io/fd/vpp/vpp/

Thanks,
Billy McFall

-- 
*Billy McFall*
SDN Group
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Connectivity issue when using vhost-user on 17.04?

[Billy McFall]

The vHost examples on the Wiki used the feature-mask of 0xFF. I think that
is how it got propagated. In 16.09 when I did the CLI documentation for the
vHost, I expanded what the bits meant and used feature-mask 0x4040 as
the example. I will gladly add an additional comment indicating that the
recommended use is to leave blank if this was intended to be debug.

https://docs.fd.io/vpp/17.07/clicmd_src_vnet_devices_virtio.html

Billy

On Thu, Apr 20, 2017 at 4:17 PM, Damjan Marion (damarion) <
damar...@cisco.com> wrote:

>
> Eric,
>
> long time ago ( i think 3+ years) when I wrote original vhost-user driver
> in vpp,
> I added feature-mask knob to cli which messes up with feature bitmap
> purely for debugging
> reasons.
>
> And I regret many times…
>
> Somebody dig it out and documented it somewhere, for to me unknown reasons.
> Now it spreads like a virus and I cannot stop it :)
>
> So please don’t use it, it is evil….
>
> Thanks,
>
> Damjan
>
> > On 20 Apr 2017, at 20:49, Ernst, Eric <eric.er...@intel.com> wrote:
> >
> > All,
> >
> > After updating the startup.conf to not reference DPDK, per direction in
> release
> > notification thread, I was able to startup vpp and create interfaces.
> >
> > Now that I'm testing, I noticed that I can no longer ping between VM
> hosts which
> > make use of vhost-user interfaces and are connected via l2 bridge domain
> > (nor l2 xconnect).  I double checked, then reverted back to 17.01, where
> I could
> > again verify connectivity between the guests.
> >
> > Any else seeing this, or was there a change in how this should be set
> up?  For
> > reference, I have my (simple) setup described @ a gist at [1].
> >
> > Thanks,
> > eric
> >
> >
> > [1] - https://gist.github.com/egernst/5982ae6f0590cd83330faafacc3fd545
> > ___
> > 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




-- 
*Billy McFall*
SDN Group
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VPP API Test Crash - Need help debugging

[Billy McFall]

I have screwed up my system and need some help fixing. Long email because
of the traces, so quick summary up front.

I was playing with pluggins and had some notes from over the summer on
running the MacSwap pluggin. I downloaded the code via:
  git clone https://github.com/alagalah/macswap-plugin

The code did not compile initially because the pluggin registration code
changed from a function call to a MACRO. I fiddle with the code and got it
to compile and install. As soon as I fired up VPP it crashed. I did not
collect the output (sorry), but in the mean time I found the sample pluggin
on the Wiki and figured it was the better route anyway. So I deleted the
all macswap*.so files I could find under /usr/* and deleted my local
sandbox with the MAC Swap changes. Now when I run VPP, it crashes, even a
recent, clean sandbox. Builds and loads fine. But when I "show
interfaces", vpp_api_test crashes (see below).

Is there something in the pluggin registration that needs to be cleaned up
that I am missing? Running on Fedora 25. Recent builds on my CentOS system
work as expect, so this most likely has something to do with how I
installed and more likely how I deleted the MAC Swap pluggin on my laptop.

Any help would be greatly appreciated,
Billy McFall


The rest is logs on the crash:

START VPP FROM CLEAN SANDBOX:

Mar 27 09:11:40 localhost systemd: Starting Vector Packet Processing
Process...
Mar 27 09:11:40 localhost systemd: Started Vector Packet Processing Process.
Mar 27 09:11:40 localhost vpp: vlib_plugin_early_init:357: plugin path
/usr/lib/vpp_plugins/
Mar 27 09:11:40 localhost vpp: load_one_plugin:187: Loaded plugin:
acl_plugin.so
Mar 27 09:11:40 localhost vpp: load_one_plugin:187: Loaded plugin:
dpdk_plugin.so
Mar 27 09:11:40 localhost vpp: load_one_plugin:187: Loaded plugin:
flowperpkt_plugin.so
Mar 27 09:11:40 localhost vpp: load_one_plugin:187: Loaded plugin:
ila_plugin.so
Mar 27 09:11:40 localhost vpp: load_one_plugin:187: Loaded plugin:
ioam_plugin.so
Mar 27 09:11:40 localhost vpp: load_one_plugin:114: Plugin disabled:
ixge_plugin.so (default)
Mar 27 09:11:40 localhost vpp: load_one_plugin:187: Loaded plugin:
lb_plugin.so
Mar 27 09:11:40 localhost vpp: load_one_plugin:187: Loaded plugin:
libsixrd_plugin.so
Mar 27 09:11:40 localhost vpp: load_one_plugin:187: Loaded plugin:
snat_plugin.so
Mar 27 09:11:40 localhost vpp: 0: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/udp_ping_test_plugin.so
Mar 27 09:11:40 localhost vpp: 0: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
Mar 27 09:11:40 localhost vpp: 0: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/acl_test_plugin.so
Mar 27 09:11:40 localhost vpp: 0: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/snat_test_plugin.so
Mar 27 09:11:40 localhost vpp: 0: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_trace_test_plugin.so
Mar 27 09:11:40 localhost vpp: 0: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
Mar 27 09:11:40 localhost vpp: 0: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
Mar 27 09:11:40 localhost vpp: 0: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/vxlan_gpe_ioam_export_test_plugin.so
Mar 27 09:11:40 localhost vpp: 0: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/flowperpkt_test_plugin.so
Mar 27 09:11:40 localhost vpp: 0: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
Mar 27 09:11:40 localhost vpp: 0: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/lb_test_plugin.so
Mar 27 09:11:40 localhost vpp: EAL: Detected 4 lcore(s)
Mar 27 09:11:40 localhost vpp: EAL: No free hugepages reported in
hugepages-1048576kB
Mar 27 09:11:40 localhost vpp: /usr/bin/vpp[31951]: dpdk_ipsec_process:241:
DPDK Cryptodev support is disabled, default to OpenSSL IPsec
Mar 27 09:11:40 localhost vpp: /usr/bin/vpp[31951]: dpdk_lib_init:557: DPDK
drivers found no ports...
Mar 27 09:11:40 localhost /usr/bin/vpp[31951]: dpdk_ipsec_process:241: DPDK
Cryptodev support is disabled, default to OpenSSL IPsec
Mar 27 09:11:40 localhost /usr/bin/vpp[31951]: dpdk_lib_init:557: DPDK
drivers found no ports...


RUN DEBUG CLI SESSION (WORKS FINE):

$ telnet 0 5002
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

vpp# show interfaces
  Name   Idx   State  Counter
 Count
local00down
vpp#


RUN NON-DEBUG CLI SESSION (CRASH):
---

Re: [vpp-dev] dpdk sw crypto- build error

[Billy McFall]

Let me know if you need anything else from me. I'll be glad to test
something if need be.

As a side note, what is the recommended version of nasm? I tested with nasm
2.12.02 on Fedora 25 and nasm 2.12.01 and 2.12.02 on Centos 7.3 and all
have the error I reported.

The version of nasm in Centos 7.3 distro is nasm 2.10.07, and it has a
different compiler error. Googled this issue and I found a link that
indicated this was fixed in a newer version of nasm, which lead me to the
nasm 2.12.02 build.
  Making object file obj/mb_mgr_hmac_submit_avx512.o
  nasm -o obj/mb_mgr_hmac_submit_avx512.o -felf64 -Xgnu -gdwarf -DLINUX
-D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/
avx512/mb_mgr_hmac_submit_avx512.asm
  avx512/mb_mgr_hmac_submit_avx512.asm:173: error: parser: instruction
expected
  avx512/mb_mgr_hmac_submit_avx512.asm:174: error: symbol `vmovdqu32'
redefined
  avx512/mb_mgr_hmac_submit_avx512.asm:174: error: parser: instruction
expected
  make[4]: *** [obj/mb_mgr_hmac_submit_avx512.o] Error 1

Thanks,
Billy McFall

On Mon, Mar 6, 2017 at 11:30 AM, Sergio Gonzalez Monroy <
sergio.gonzalez.mon...@intel.com> wrote:

> Hi Billy,
>
> It seems that things have changed a bit since DPDK is built as a plugin
> and we are looking into this issue.
>
> I'll update once I have more details.
>
> Regards,
> Sergio
>
> On 03/03/2017 16:59, Billy McFall wrote:
>
> Like the original email on this thread, I am trying to build latest vpp
> with vpp_uses_dpdk_cryptodev_sw = yes option to enable vpp sw crypto. The
> difference is I am running on Fedora 25. I attempted to followed the
> suggestions in this email chain:
> * I updated /build-data/platforms/vpp.mk with  "-Wl,--whole-archive,-l:
> libIPSec_MB.a,--no-whole-archive" and copied libIPSec_MB.a into /usr/lib/.
> * I set link_all_deplibs to yes in vpp/build-root/build-vpp-
> native/dpdk/isa-l_crypto-master/aclocal.m4 after running 'make
> bootstrap', which set it in vpp/build-root/build-vpp-native/vpp/libtool.
>
> If anyone has instructions on how to update libtool from source, I will
> attempt that.
>
>
> Below is the error I am seeing:
>
> make[3]: Entering directory '/home/bmcfall/dev/2017_03_03_
> VPP_Master/vpp/build-root/build-vpp-native/vpp'
>   CCLD libvppinfra.la
> /usr/bin/ld: /home/bmcfall/dev/2017_03_03_VPP_Master/vpp/build-root/
> install-vpp-native/dpdk/lib/libIPSec_MB.a(aes128_cntr_by4_sse.o):
> relocation R_X86_64_PC32 against symbol `byteswap_const' can not be used
> when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
> Makefile:4564: recipe for target 'libvppinfra.la' failed
> make[3]: *** [libvppinfra.la] Error 1
>
>
> I am also seeing a lot of warnings when the dpdk/crypto is being built
> (this is just a snippet, I am seeing a lot more):
>
> make[4]: Entering directory '/home/bmcfall/dev/2017_03_03_
> VPP_Master/vpp/build-root/build-vpp-native/dpdk/isa-l_crypto-master'
> Building isa-l_crypto.h
> make --no-print-directory all-am
>   CC   md5_mb/md5_ctx_sse.lo
>   CC   md5_mb/md5_ctx_avx.lo
>   CC   md5_mb/md5_ctx_avx2.lo
>   CC   md5_mb/md5_mb_mgr_init_sse.lo
>   CC   md5_mb/md5_mb_mgr_init_avx2.lo
>   CC   md5_mb/md5_mb_mgr_init_avx512.lo
>   MKTMPmd5_mb/md5_mb_mgr_submit_sse.s
>   CCAS md5_mb/md5_mb_mgr_submit_sse.lo
> md5_mb/md5_mb_mgr_submit_sse.s:151: warning: absolute address can not be
> RIP-relative
>   MKTMPmd5_mb/md5_mb_mgr_submit_avx.s
>   CCAS md5_mb/md5_mb_mgr_submit_avx.lo
> md5_mb/md5_mb_mgr_submit_avx.s:150: warning: absolute address can not be
> RIP-relative
>   MKTMPmd5_mb/md5_mb_mgr_submit_avx2.s
>   CCAS md5_mb/md5_mb_mgr_submit_avx2.lo
> md5_mb/md5_mb_mgr_submit_avx2.s:159: warning: absolute address can not be
> RIP-relative
>   MKTMPmd5_mb/md5_mb_mgr_flush_sse.s
>   CCAS md5_mb/md5_mb_mgr_flush_sse.lo
> md5_mb/md5_mb_mgr_flush_sse.s:119: warning: absolute address can not be
> RIP-relative
> md5_mb/md5_mb_mgr_flush_sse.s:121: warning: absolute address can not be
> RIP-relative
> md5_mb/md5_mb_mgr_flush_sse.s:123: warning: absolute address can not be
> RIP-relative
> md5_mb/md5_mb_mgr_flush_sse.s:125: warning: absolute address can not be
> RIP-relative
> md5_mb/md5_mb_mgr_flush_sse.s:127: warning: absolute address can not be
> RIP-relative
> md5_mb/md5_mb_mgr_flush_sse.s:129: warning: absolute address can not be
> RIP-relative
> md5_mb/md5_mb_mgr_flush_sse.s:131: warning: absolute address can not be
> RIP-relative
> md5_mb/md5_mb_mgr_flush_sse.s:164: warning: absolute address can not be
> RIP-relative
>   MKTMPmd5_mb/md5_mb_mgr_flush_avx.s
>   CCAS md5_mb/md5_mb_mgr_flush_avx.lo
&

Re: [vpp-dev] dpdk sw crypto- build error

[Billy McFall]

Like the original email on this thread, I am trying to build latest vpp
with vpp_uses_dpdk_cryptodev_sw = yes option to enable vpp sw crypto. The
difference is I am running on Fedora 25. I attempted to followed the
suggestions in this email chain:
* I updated /build-data/platforms/vpp.mk with
 "-Wl,--whole-archive,-l:libIPSec_MB.a,--no-whole-archive" and copied
libIPSec_MB.a into /usr/lib/.
* I set link_all_deplibs to yes
in vpp/build-root/build-vpp-native/dpdk/isa-l_crypto-master/aclocal.m4
after running 'make bootstrap', which set it in
vpp/build-root/build-vpp-native/vpp/libtool.

If anyone has instructions on how to update libtool from source, I will
attempt that.


Below is the error I am seeing:

make[3]: Entering directory
'/home/bmcfall/dev/2017_03_03_VPP_Master/vpp/build-root/build-vpp-native/vpp'
  CCLD libvppinfra.la
/usr/bin/ld:
/home/bmcfall/dev/2017_03_03_VPP_Master/vpp/build-root/install-vpp-native/dpdk/lib/libIPSec_MB.a(aes128_cntr_by4_sse.o):
relocation R_X86_64_PC32 against symbol `byteswap_const' can not be used
when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Makefile:4564: recipe for target 'libvppinfra.la' failed
make[3]: *** [libvppinfra.la] Error 1


I am also seeing a lot of warnings when the dpdk/crypto is being built
(this is just a snippet, I am seeing a lot more):

make[4]: Entering directory
'/home/bmcfall/dev/2017_03_03_VPP_Master/vpp/build-root/build-vpp-native/dpdk/isa-l_crypto-master'
Building isa-l_crypto.h
make --no-print-directory all-am
  CC   md5_mb/md5_ctx_sse.lo
  CC   md5_mb/md5_ctx_avx.lo
  CC   md5_mb/md5_ctx_avx2.lo
  CC   md5_mb/md5_mb_mgr_init_sse.lo
  CC   md5_mb/md5_mb_mgr_init_avx2.lo
  CC   md5_mb/md5_mb_mgr_init_avx512.lo
  MKTMPmd5_mb/md5_mb_mgr_submit_sse.s
  CCAS md5_mb/md5_mb_mgr_submit_sse.lo
md5_mb/md5_mb_mgr_submit_sse.s:151: warning: absolute address can not be
RIP-relative
  MKTMPmd5_mb/md5_mb_mgr_submit_avx.s
  CCAS md5_mb/md5_mb_mgr_submit_avx.lo
md5_mb/md5_mb_mgr_submit_avx.s:150: warning: absolute address can not be
RIP-relative
  MKTMPmd5_mb/md5_mb_mgr_submit_avx2.s
  CCAS md5_mb/md5_mb_mgr_submit_avx2.lo
md5_mb/md5_mb_mgr_submit_avx2.s:159: warning: absolute address can not be
RIP-relative
  MKTMPmd5_mb/md5_mb_mgr_flush_sse.s
  CCAS md5_mb/md5_mb_mgr_flush_sse.lo
md5_mb/md5_mb_mgr_flush_sse.s:119: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_sse.s:121: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_sse.s:123: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_sse.s:125: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_sse.s:127: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_sse.s:129: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_sse.s:131: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_sse.s:164: warning: absolute address can not be
RIP-relative
  MKTMPmd5_mb/md5_mb_mgr_flush_avx.s
  CCAS md5_mb/md5_mb_mgr_flush_avx.lo
md5_mb/md5_mb_mgr_flush_avx.s:119: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_avx.s:121: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_avx.s:123: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_avx.s:125: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_avx.s:127: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_avx.s:129: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_avx.s:131: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_mgr_flush_avx.s:163: warning: absolute address can not be
RIP-relative
:
  CCAS md5_mb/md5_mb_x4x2_sse.lo
md5_mb/md5_mb_x4x2_sse.s:361: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_x4x2_sse.s:539: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_x4x2_sse.s:162: ... from macro `MD5_STEP1' defined here
md5_mb/md5_mb_x4x2_sse.s:120: ... from macro `MAGIC_I' defined here
md5_mb/md5_mb_x4x2_sse.s:539: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_x4x2_sse.s:164: ... from macro `MD5_STEP1' defined here
md5_mb/md5_mb_x4x2_sse.s:120: ... from macro `MAGIC_I' defined here
md5_mb/md5_mb_x4x2_sse.s:540: warning: absolute address can not be
RIP-relative
md5_mb/md5_mb_x4x2_sse.s:162: ... from macro `MD5_STEP1' defined here
md5_mb/md5_mb_x4x2_sse.s:120: ... from macro `MAGIC_I' defined here
:

Any suggestions would be greatly appreciated,
Billy McFall

On Fri, Feb 24, 2017 at 7:03 AM, yusuf khan <yusuf.at...@gmail.com> wrote:

> Hi All,
>
> As Radu suggested, after updating libtool from source it works fine.
>
> Thanks a lot everyone.
>
> Br
> Yusuf
>
> On 24-Feb-2017 1:49 PM, "Chen, Zhaoyan"

Re: [vpp-dev] How do I create a igb_uio module on Centos

[Billy McFall]

I have been editing ../vpp/dpdk/Makefile, search for IGB_UIO and change the
n to a y.

Billy

On Sat, Feb 18, 2017 at 6:31 AM, Damjan Marion 
wrote:

>
> On 18 Feb 2017, at 05:48, Burt Silverman  wrote:
>
> Hi,
>
> I am trying to follow the procedures on https://wiki.fd.io/view/
> VPP/Build,_install,_and_test_images and https://wiki.fd.io/view/
> VPP/How_To_Connect_A_PCI_Interface_To_VPP but I end up with no igb_uio
> module; so I cannot
> # modprobe igb_uio
>
> and that seems to correspond to
>
>- *vpp-dpdk-dkms* - DKMS based DPDK kernel module package (only on
>Debian/Ubuntu)
>
>
> from https://wiki.fd.io/view/VPP/Build,_install,_and_test_images
>
> so what is the workflow when using Centos? The wiki indicates that no
> special workflow is required for Centos other than using systemd commands
> rather than upstart commands.
>
>
> We never made this working on centos, as we use uio_pci_generic. Why do
> you need igb_uio?
>
>
> ___
> 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] show interface address with multiple tables

[Billy McFall]

Dave, I agree with your statements about VPP probably needs to add the
verification. I wanted to add that this constraint was added to the Doxygen
documentation. But there are a lot of constraints that are not documented,
and if they are, I'm not sure how to better propagate the information to
masses.

>From the Doxygen documentation for "set interface ip table":

*Note*
IP addresses added after setting the interface IP table end up in the
indicated FIB table. If the IP address is added prior to adding the
interface to the FIB table, it will NOT be part of the FIB table.
Predictable but potentially counter-intuitive results occur if you
provision interface addresses in multiple FIBs. Upon RX, packets will be
processed in the last IP table ID provisioned. It might be marginally
useful to evade source RPF drops to put an interface address into multiple
FIBs.

Billy McFall

On Tue, Jan 17, 2017 at 9:45 AM, Dave Wallace <dwallac...@gmail.com> wrote:

> Neale,
>
> Given this constraint, IMO it should be verified prior to enacting the
> change of the interface table and the request should be rejected if the
> constraint is not met.  The $64,000 question is whether this constraint
> should be verified by VPP itself or the management agent.
>
> Prior to open sourcing VPP, when there was a dedicated management agent,
> Dave and I agreed that constraint verification was the responsibility of
> the management agent.
>
> Now that VPP is open source and there are potentially numerous management
> agents, it seems to me that including configuration constraint verification
> in the VPP might make more sense as a defensive mechanism.
>
> In either case, there is a general lack of documentation on feature
> constraints that needs to be addressed.  In the past, I have worked on a
> system where the entire set of system configuration constraints was
> documented in the bug tracking system.  Needless to say, this was a less
> than optimal means of communicating the set of requirements.
>
> Thanks,
> -daw-
>
>
> On 1/17/2017 2:20 AM, Neale Ranns (nranns) wrote:
>
>
>
> Hi Choonho,
>
>
>
> An interface can only reside in (a.k.a be bound to) a single table. So
> each time you do;
>
>   Set int ip table loop0 X
>
> You are changing the table it is bound to, not adding tables. So the
> output you see at the end of the sequence is correct, the loopback has two
> addresses and is bound to table 5.
>
>
>
> However, this is not a supported sequence of events. You MUST remove all
> configured IP address on an interface before you change the interface’s
> table.
>
>
>
> Regards,
>
> neale
>
>
>
>
>
> *From: *<vpp-dev-boun...@lists.fd.io> <vpp-dev-boun...@lists.fd.io> on
> behalf of Choonho Son <choonho@gmail.com> <choonho@gmail.com>
> *Date: *Tuesday, 17 January 2017 at 00:17
> *To: *"vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io>
> <vpp-dev@lists.fd.io>
> *Subject: *[vpp-dev] show interface address with multiple tables
>
>
>
> With multiple tables(VRF), show interface addr display wrong table ID.
> DBGvpp# create loopback interface
> loop0
> DBGvpp# set interface ip table loop0 1
> DBGvpp# set interface ip address loop0 1.0.0.250/16
> DBGvpp# sh int addr
> local0 (dn):
> loop0 (dn):
> 1.0.0.250/16 table 1
> DBGvpp# set interface ip table loop0 5
> DBGvpp# set interface ip address loop0 5.0.0.250/16
> DBGvpp# sh int addr
> local0 (dn):
> loop0 (dn):
> 1.0.0.250/16 table 5
> 5.0.0.250/16 table 5
> DBGvpp#
> The reason looks like
> ip4_main_t has single fib_index_by_sw_if_index.
> Even though sw_if_index has two table ID(fib_index) 1 and 5.
> Last updated fib_index(Table 5) is updated at ip4_main_t.
>
>
>
> ___
> vpp-dev mailing 
> listvpp-...@lists.fd.iohttps://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] VPP Build Bombing Out on libsvm.la?

[Billy McFall]

I build on CentOS and Fedora regularly, though it has been Fedora more
recently. I haven't seen it bail on vppifra, but I will go kick off a fresh
sandbox on CentOS right now. In the meantime, here are my steps on a fresh
sandbox:
   cd vpp;  make install-dep;  make bootstrap;  make build-release;  make
pkg-rpm

After some git activity, such as pushing a patch, the .version file becomes
stale and needs to be regenerated. So I run:
   cd vpp;  make wipe;

I'll let you know what I find on a fresh build.

Billy McFall

On Wed, Jan 11, 2017 at 6:29 PM, Dave Barach (dbarach) <dbar...@cisco.com>
wrote:

> Here’s what I do when switching branches:
>
>
>
> $ cd build-root
>
> $ make distclean
>
> $ cd ../
>
> $ git clean -fx
>
> $ cd build-root
>
> $ ./bootstrap.sh
>
> $ # build should work
>
>
>
> HTH… Dave
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Burt Silverman
> *Sent:* Wednesday, January 11, 2017 5:46 PM
> *To:* Jon Loeliger <j...@netgate.com>
> *Cc:* vpp-dev <vpp-dev@lists.fd.io>
> *Subject:* Re: [vpp-dev] VPP Build Bombing Out on libsvm.la?
>
>
>
> I don't have a great answer, but this is something I would try.
>
> If you have a clean git repository, with no local uncommitted
> modifications (if you have any, then stash them so they won't be lost), I
> would try from the top of the tree:
>
> $ rm -rf *  #make sure you do not use .*
>
> $ git checkout .
>
> Now try your entire build sequence again.
>
> The reasoning is: if you checkout an older level AND build AND then switch
> to master, sometimes some crud is left around. Although one would expect
> that crud to be harmless, it cannot hurt for you to do an extra check. More
> sophisticated debugging can be done if the problem does not get solved this
> simple(ton) way.
>
> Burt
>
>
>
> On Wed, Jan 11, 2017 at 4:59 PM, Jon Loeliger <j...@netgate.com> wrote:
>
> Folks,
>
>
>
> I'm staring at some VPP builds on a fresh CentOS system.
>
> I've installed all the "install-deps", and get pretty far into the
>
> build before it wedges.  I see warnings like this:
>
>
>
>  /bin/sh ./libtool   --mode=install /usr/bin/install -c   libsvm.la
> libsvmdb.la libvlib.la libvlibapi.la libvlibmemory.la
> libvlibmemoryclient.la libvlibsocket.la libvatplugin.la
> '/home/jdl/ngr-rpms/build_root/BUILD/vpp/build-root/
> install-vpp-native/vpp/lib64'
>
> PLUGIN CFG vpp_plugin_configure
>
> libtool: install: warning: relinking `libsvm.la'
>
>
>
> I don't know if that is important misbehavior or normal behavior.
>
>
>
> Ultimately, most of the builds quit grousing about a missing libvppinfra:
>
>
>
> /usr/bin/ld: cannot find -lvppinfra
>
> collect2: error: ld returned 1 exit status
>
> libtool: install: error: relink `libsvm.la' with the above command before
> installing it
>
> make[6]: *** [install-libLTLIBRARIES] Error 1
>
> make[6]: *** Waiting for unfinished jobs
>
>
>
> Not sure which real target issued that loveliness due to some "make -j"
>
> parallelism in the mix.  Might be the relinking of libvnet.la.
>
>
>
> I am able to build VPP on an entirely different system though.
>
> So it seems like there is some variability in its success rate.
>
>
>
> Is it possible that there is a missing dependency and the "-j" is
>
> effectively causing it to want libvppinfra before it is available?
>
>
>
> Ideas or suggestions?
>
>
> Thanks,
>
> jdl
>
>
>
>
> ___
> 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] Jira Workflow

[Billy McFall]

Following the Jira workflow, I have marked several Jira bugs "Complete".
When are they marked closed and who is responsible for making the change?
  https://wiki.fd.io/view/VPP/jira_workflow

For some of the documentation Jira bugs, I added @todo and moved on. For
those, do you want me to move the associated Jira to "Complete" or leave
open until all the @todo get fixed? Or should new Jira bugs for the @todo
be written?

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

Re: [vpp-dev] Build Errors

[Billy McFall]

Long, but below are the three types of errors I hit. I am writing a Jira
now and will submit a patch to fix them later today.

*1) There is a semi-colon at the end of the if statement. Fix was merged
yesterday.*

*vnet/vnet/fib/fib_entry_src_interface.c*

starting at line 54

  if (IP_LOOKUP_NEXT_GLEAN == adj->lookup_next_index);
 {

My Error Output:
/home/bmcfall/dev/2016_10_11_VPP_286_ip_doxygen/vpp/build-
data/../vnet/vnet/fib/fib_entry_src_interface.c: In function
‘fib_entry_src_interface_path_swap’:
/home/bmcfall/dev/2016_10_11_VPP_286_ip_doxygen/vpp/build-
data/../vnet/vnet/fib/fib_entry_src_interface.c:54:2: error: this ‘if’
clause does not guard... [-Werror=misleading-indentation]
  if (IP_LOOKUP_NEXT_GLEAN == adj->lookup_next_index);
  ^~
/home/bmcfall/dev/2016_10_11_VPP_286_ip_doxygen/vpp/build-
data/../vnet/vnet/fib/fib_entry_src_interface.c:55:9: note: ...this
statement, but the latter is misleadingly indented as if it is guarded by
the ‘if’
 {
 ^

*2) Couple of "defined but not used" errors:*

*/vnet/vnet/mpls/interface.c*
starting on line 535

 static const int dpo_next_2_mpls_post_rewrite[DPO_LAST] = {
   [DPO_LOAD_BALANCE] = IP_LOOKUP_NEXT_LOAD_BALANCE,


My Error Output:
/home/bmcfall/dev/2016_10_11_VPP_286_ip_doxygen/vpp/build-
data/../vnet/vnet/mpls/interface.c:536:18: error:
‘dpo_next_2_mpls_post_rewrite’ defined but not used [-Werror=unused-const-
variable=]
 static const int dpo_next_2_mpls_post_rewrite[DPO_LAST] = {
  ^~~~
cc1: all warnings being treated as errors


*/vnet/vnet/dpo/lookup_dpo.c*
starting on line 797

const static char* const lookup_dst_from_interface_ip4_nodes[] =
{
"lookup-ip4-dst-itf",
NULL,
};
const static char* const lookup_dst_from_interface_ip6_nodes[] =
{
"lookup-ip6-dst-itf",
NULL,
};
const static char* const lookup_dst_from_interface_mpls_nodes[] =
{
"lookup-mpls-dst-itf",
NULL,
};
const static char* const * const lookup_dst_from_interface_nodes[DPO_PROTO_NUM]
=
{
[DPO_PROTO_IP4]  = lookup_dst_from_interface_ip4_nodes,
[DPO_PROTO_IP6]  = lookup_dst_from_interface_ip6_nodes,
[DPO_PROTO_MPLS] = lookup_dst_from_interface_mpls_nodes,
};


My Error Output:
/home/bmcfall/dev/2016_10_11_VPP_286_ip_doxygen/vpp/build-
data/../vnet/vnet/dpo/lookup_dpo.c:813:34: error:
‘lookup_dst_from_interface_nodes’ defined but not used
[-Werror=unused-const-variable=]
 const static char* const * const
lookup_dst_from_interface_nodes[DPO_PROTO_NUM]
=
  ^~~
cc1: all warnings being treated as errors


*3) va_arg() parameter issue:*

There are multiple instances of this. The first example is in
/vnet/vnet/lisp-gpe/lisp_gpe_adjacency.c, but around 9 other files hit the
same issue.

starting at line 358

  lisp_gpe_adjacency_format_flags_t flags =
va_arg (args, lisp_gpe_adjacency_format_flags_t);


I looked around the code, and other calls to va_arg() de-reference the
pointer to the variable 'args'. 'man va_arg()' indicates that the first
parameter is of type va_list. When I did this it compiled clean.

  lisp_gpe_adjacency_format_flags_t flags =
va_arg (*args, lisp_gpe_adjacency_format_flags_t);


My Error Output:
  CC   vnet/dpo/lookup_dpo.lo
/home/bmcfall/dev/2016_10_11_VPP_286_ip_doxygen/vpp/build-
data/../vnet/vnet/lisp-gpe/lisp_gpe_adjacency.c: In function
‘format_lisp_gpe_adjacency’:
/home/bmcfall/dev/2016_10_11_VPP_286_ip_doxygen/vpp/build-
data/../vnet/vnet/lisp-gpe/lisp_gpe_adjacency.c:359:5: internal compiler
error: in build_va_arg, at c-family/c-common.c:5812
 va_arg (args, lisp_gpe_adjacency_format_flags_t);
 ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccVa8tTa.out file, please attach this
to your bugreport.

On Thu, Oct 13, 2016 at 10:08 AM, Damjan Marion (damarion) <
damar...@cisco.com> wrote:

>
> Hi Bill,
>
> Error output copy/pasted here or to pastebin will be a good start.
>
> Thanks,
>
> Damjan
>
> > On 13 Oct 2016, at 15:55, Billy McFall <bmcf...@redhat.com> wrote:
> >
> > I am getting build errors from a newly created sandbox based off master.
> The build errors are coming from a patch submitted 3 weeks ago. One of the
> errors was fixed yesterday as a Coverity warning. So my question is, what
> is different on my system that these are treated as errors but I haven't
> anyone else on the message board seeing the errors? Do I have an old or new
> compiler? Some additional setting? What can I dump to provide more
> information?
> >
> > Host OS: Fedora 24
> > # gcc --version
> > gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
> > Copyright (C) 2016 Free Software Foundation, Inc.
> > This is fr

[vpp-dev] Build Errors

[Billy McFall]

I am getting build errors from a newly created sandbox based off master.
The build errors are coming from a patch submitted 3 weeks ago. One of the
errors was fixed yesterday as a Coverity warning. So my question is, what
is different on my system that these are treated as errors but I haven't
anyone else on the message board seeing the errors? Do I have an old or new
compiler? Some additional setting? What can I dump to provide more
information?

Host OS: Fedora 24
# gcc --version
gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

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