[vpp-dev] Coverity run FAILED as of 2019-12-29 14:00:24 UTC

[Noreply Jenkins]

Coverity run failed today.

Current number of outstanding issues are 2
Newly detected: 0
Eliminated: 0
More details can be found at  
https://scan.coverity.com/projects/fd-io-vpp/view_defects
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] Discrepancies between CI jobs and s5ci

[Dave Barach via Lists.Fd.Io]

I would just as soon keep the story as simple as possible. “sudo make 
test[-debug]” => run both test-runner and vpp privileged. “make test[-debug]” 
means run neither one privileged.

FWIW... Dave

From: Paul Vinciguerra 
Sent: Saturday, December 28, 2019 12:22 PM
To: Dave Barach (dbarach) 
Cc: Andrew Yourtchenko ; vpp-dev 
Subject: Re: [vpp-dev] Discrepancies between CI jobs and s5ci

Hi Dave.

If you don't mind, would you clarify your statement further?  Is it your desire 
that 'make test[-debug]' be launched without privileges, or
is it that since VPP is a userspace application, you want to verify 
functionality without any further dependencies on the kernel creeping in?

The reason I'm asking is that because since you are aware of how the framework 
tightly couples the permissions of the test runner and
the forked VPP process, you know that launching the test runner without 
privileges is the current way we ensure that VPP runs without privileges.
We could have the runner run privileged and drop the capabilities of the forked 
VPP process by default.
Today, 'make run' runs vpp under sudo.

My thought is that a test needing additional capabilities could set a class 
attribute of say capabilities = ['cap_net_admin'] and
we could add that capability for the single test suite and report accordingly. 
Something like:


TAP Test Case

[W173] Create TAP interface fails with insufficient permissions 
 0.00 OK
[W173] Connect to existing TAP interface
 0.00 OK

TAP Test Case
capabilities = ['cap_net_admin']

[W176] Create TAP interface 
 0.22 OK


If the runner is running unprivileged, we would skip:


TAP Test Case
capabilities = ['cap_net_admin']

[W176] Create TAP interface 
 0.00 SKIP [ runner can't grant necessary capabilities. ]


On Sat, Dec 28, 2019 at 7:44 AM Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> wrote:
My $0.02: I would like “make test[-debug]” to work without privileges.

Thanks... Dave

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Andrew 
Yourtchenko
Sent: Friday, December 27, 2019 7:21 PM
To: Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Discrepancies between CI jobs and s5ci



On 27 Dec 2019, at 22:48, Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>> wrote:

Hi Andrew.
That was the test that caught my attention.  I am of the opinion that s5ci 
provides the behavior we expect.

I personally has requested the tap test in its time to be moved to extended 
tests, because of this.

I presume the parties who made it appear in the standard tests will either 
chime into this discussion with their reasoning or will make it disappear :-)


I have a changeset that skips the test on s5ci instead of failing [0], but I 
actually think that the proper test for the CI is a test where the test fails, 
reporting insufficient permissions, since that is what an unprivileged use 
would see.

[0] https://gerrit.fd.io/r/c/vpp/+/24132

One can not decide if the lack of privileges is due to misconfiguration or due 
to intent, so there is no place for adaptivity and automagicness in this 
context.

If we all agree that “make test” is supposed to succeed in the unprivileged 
environment then it should, end of story. With the exact same tests as in 
privileged environment.

And then for the more demanding tests there should be some sort of  
“PRIVILEGED=yes make test” alternative that will invoke the tests that require 
additional privileges and fail if it doesn’t get them. With potentially more 
granular set of valued for “yes”.

Testing is about determinism.

—a


On Fri, Dec 27, 2019 at 4:27 PM Andrew 👽 Yourtchenko 
mailto:ayour...@gmail.com>> wrote:
I was under impression the “make test” was supposed to be passing when run 
under the regular user. That means that the recently added tap tests will make 
it fail: http://s5ci.myvpp.net/jobs/vpp-periodic-make-verify/ is only failures 
as of 12:25 UTC 24th December.

So, what is the direction the community wants to go ?

--a

On 27 Dec 2019, at 17:22, Paul Vinciguerra 
mailto:pvi...@vinci

Re: [vpp-dev] Discrepancies between CI jobs and s5ci

[Damjan Marion via Lists.Fd.Io]

+1, simple is key here

I think that we simply should remove that tap test as it falls under device 
driver tests which we don't test in make test framework.

PS I really don't like direction where test framework is going,
originally it was very simple to write tests even without having python 
knowledge, it was simple copy/paste learn ty example exercise.
Today you need to have advanced python skills even to understand what tests 
does. As i don't have any intention to grow my python skills, I can only 
declare myself as not capable to write any test case...

-- 
Damjan

> On 29 Dec 2019, at 20:09, Dave Barach via Lists.Fd.Io 
>  wrote:
> 
> I would just as soon keep the story as simple as possible. “sudo make 
> test[-debug]” => run both test-runner and vpp privileged. “make test[-debug]” 
> means run neither one privileged.
>  
> FWIW... Dave
>  
> From: Paul Vinciguerra  > 
> Sent: Saturday, December 28, 2019 12:22 PM
> To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
> Cc: Andrew Yourtchenko mailto:ayour...@gmail.com>>; 
> vpp-dev mailto:vpp-dev@lists.fd.io>>
> Subject: Re: [vpp-dev] Discrepancies between CI jobs and s5ci
>  
> Hi Dave.
>  
> If you don't mind, would you clarify your statement further?  Is it your 
> desire that 'make test[-debug]' be launched without privileges, or 
> is it that since VPP is a userspace application, you want to verify 
> functionality without any further dependencies on the kernel creeping in?
>  
> The reason I'm asking is that because since you are aware of how the 
> framework tightly couples the permissions of the test runner and 
> the forked VPP process, you know that launching the test runner without 
> privileges is the current way we ensure that VPP runs without privileges.  
> We could have the runner run privileged and drop the capabilities of the 
> forked VPP process by default. 
> Today, 'make run' runs vpp under sudo.
>  
> My thought is that a test needing additional capabilities could set a class 
> attribute of say capabilities = ['cap_net_admin'] and 
> we could add that capability for the single test suite and report 
> accordingly. Something like:
>  
> 
> TAP Test Case
> 
> [W173] Create TAP interface fails with insufficient permissions   
>0.00 OK
> [W173] Connect to existing TAP interface  
>0.00 OK
> 
> TAP Test Case
> capabilities = ['cap_net_admin']
> 
> [W176] Create TAP interface   
>0.22 OK
> 
> 
> 
> If the runner is running unprivileged, we would skip:
> 
> 
> TAP Test Case
> capabilities = ['cap_net_admin']
> 
> [W176] Create TAP interface   
>0.00 SKIP [ runner can't grant necessary capabilities. ]
> 
>  
> On Sat, Dec 28, 2019 at 7:44 AM Dave Barach (dbarach)  > wrote:
> My $0.02: I would like “make test[-debug]” to work without privileges.
>  
> Thanks... Dave
>  
> From: vpp-dev@lists.fd.io   > On Behalf Of Andrew Yourtchenko
> Sent: Friday, December 27, 2019 7:21 PM
> To: Paul Vinciguerra  >
> Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Subject: Re: [vpp-dev] Discrepancies between CI jobs and s5ci
>  
>  
>  
> 
> On 27 Dec 2019, at 22:48, Paul Vinciguerra  > wrote:
> 
> 
> Hi Andrew.
> That was the test that caught my attention.  I am of the opinion that s5ci 
> provides the behavior we expect. 
>  
> I personally has requested the tap test in its time to be moved to extended 
> tests, because of this.
>  
> I presume the parties who made it appear in the standard tests will either 
> chime into this discussion with their reasoning or will make it disappear :-)
>  
>  
> 
> I have a changeset that skips the test on s5ci instead of failing [0], but I 
> actually think that the proper test for the CI is a test where the test 
> fails, reporting insufficient permissions, since that is what an unprivileged 
> use would see.
>  
> [0] https://gerrit.fd.io/r/c/vpp/+/24132 
> 
>  
> One can not decide if the lack of privileges is due to misconfiguration or 
> due

Re: [vpp-dev] Discrepancies between CI jobs and s5ci

[Balaji Venkatraman via Lists.Fd.Io]

I agree with Damjan on this.

Seems convoluted to comprehend and enhance the suite. I think, it isn’t very 
intuitive. But I guess we are tied to python to interface with the tools 
(scapy, trex, blah for traffic profiles)?


--
Regards,
Balaji.


From:  on behalf of "Damjan Marion via Lists.Fd.Io" 

Reply-To: "dmar...@me.com" 
Date: Sunday, December 29, 2019 at 11:21 AM
To: "Dave Barach (dbarach)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Discrepancies between CI jobs and s5ci


+1, simple is key here

I think that we simply should remove that tap test as it falls under device 
driver tests which we don't test in make test framework.

PS I really don't like direction where test framework is going,
originally it was very simple to write tests even without having python 
knowledge, it was simple copy/paste learn ty example exercise.
Today you need to have advanced python skills even to understand what tests 
does. As i don't have any intention to grow my python skills, I can only 
declare myself as not capable to write any test case...

--
Damjan


On 29 Dec 2019, at 20:09, Dave Barach via Lists.Fd.Io 
mailto:dbarach=cisco@lists.fd.io>> wrote:

I would just as soon keep the story as simple as possible. “sudo make 
test[-debug]” => run both test-runner and vpp privileged. “make test[-debug]” 
means run neither one privileged.

FWIW... Dave

From: Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>>
Sent: Saturday, December 28, 2019 12:22 PM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
Cc: Andrew Yourtchenko mailto:ayour...@gmail.com>>; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Discrepancies between CI jobs and s5ci

Hi Dave.

If you don't mind, would you clarify your statement further?  Is it your desire 
that 'make test[-debug]' be launched without privileges, or
is it that since VPP is a userspace application, you want to verify 
functionality without any further dependencies on the kernel creeping in?

The reason I'm asking is that because since you are aware of how the framework 
tightly couples the permissions of the test runner and
the forked VPP process, you know that launching the test runner without 
privileges is the current way we ensure that VPP runs without privileges.
We could have the runner run privileged and drop the capabilities of the forked 
VPP process by default.
Today, 'make run' runs vpp under sudo.

My thought is that a test needing additional capabilities could set a class 
attribute of say capabilities = ['cap_net_admin'] and
we could add that capability for the single test suite and report accordingly. 
Something like:


TAP Test Case

[W173] Create TAP interface fails with insufficient permissions 
 0.00 OK
[W173] Connect to existing TAP interface
 0.00 OK

TAP Test Case
capabilities = ['cap_net_admin']

[W176] Create TAP interface 
 0.22 OK



If the runner is running unprivileged, we would skip:


TAP Test Case
capabilities = ['cap_net_admin']

[W176] Create TAP interface 
 0.00 SKIP [ runner can't grant necessary capabilities. ]


On Sat, Dec 28, 2019 at 7:44 AM Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> wrote:
My $0.02: I would like “make test[-debug]” to work without privileges.

Thanks... Dave

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Andrew 
Yourtchenko
Sent: Friday, December 27, 2019 7:21 PM
To: Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Discrepancies between CI jobs and s5ci



On 27 Dec 2019, at 22:48, Paul Vinciguerra 
mailto:pvi...@vinciconsulting.com>> wrote:
Hi Andrew.
That was the test that caught my attention.  I am of the opinion that s5ci 
provides the behavior we expect.

I personally has requested the tap test in its time to be moved to extended 
tests, because of this.

I presume the parties who made it appear in the standard tests will either 
chime into this discussion with their reasoning or will make it disappear :-)


I have a changeset that skips the test on s5ci instead of failing [0], but I 
actually think that the proper test f

[vpp-dev] How to show all configurations and save configuration at runtime?

[Xiaopeng Bai]

Hi, guys!

How can i show all current configurations and save it？
Someone can help me? Thx

Best Regeards,
Xiaopeng
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] VPP Crash while programming DPO from a VPP Worker

[Satya Murthy]

Hi,

We are seeing a VPP crash (ASSERT) with following stack trace, when we try to 
create a DPO from within a VPP worker.
The below crash clear shows that DPO creation is restricted only to the main 
thread, since the ASSERT is making sure that the thread id is 0.

*  Backtrace of "Thread workers 1" (0xd11ca700)
*      Frame 00: /lib64/libc.so.6(gsignal+0x10b) [0x7f3b860e1feb]
*      Frame 01: /lib64/libc.so.6(abort+0x12b) [0x7f3b860cc5c1]
*      Frame 02: /usr/bin/vpp() [0x407e83]
*      Frame 03: 
/lib64/libvlib.so.18.10(vlib_worker_thread_barrier_sync_int+0x2c8) 
[0x7f3b877d6298]
*      Frame 04: /lib64/libvnet.so.18.10(dpo_stack+0x3fe) [0x7f3b881176be]
*      Frame 05: /lib64/libvnet.so.18.10(+0x5134ad) [0x7f3b8811a4ad]
*      Frame 06: /lib64/libvnet.so.18.10(load_balance_multipath_update+0xe8) 
[0x7f3b8811cb48]
*      Frame 07: /lib64/libvnet.so.18.10(fib_entry_src_mk_lb+0x13e) 
[0x7f3b880ff4ee]
*      Frame 08: /lib64/libvnet.so.18.10(fib_entry_src_action_install+0xc5) 
[0x7f3b880ff7d5]
*      Frame 09: /lib64/libvnet.so.18.10(fib_entry_create_special+0x39) 
[0x7f3b880fd129]
*      Frame 10: /lib64/libvnet.so.18.10(fib_table_entry_special_dpo_add+0xd5) 
[0x7f3b880f4215]

void
vlib_worker_thread_barrier_sync_int (vlib_main_t * vm)
{

ASSERT (vlib_get_thread_index () == 0);  < Crash is happening here
}
So, now the question is:
Can't we create any DPO from a worker thread ?
If not, is there any work around to do this.

Please let us know any inputs on this.

--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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