Re: [vpp-dev] show interface address with multiple tables

2017-01-16 Thread Neale Ranns (nranns)

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:  on behalf of Choonho Son 

Date: Tuesday, 17 January 2017 at 00:17
To: "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 list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] rte_timer

2017-01-16 Thread yug...@telincn.com
I have tried that now, and it's working.

Thanks,
Ewan



yug...@telincn.com
 
From: Damjan Marion
Date: 2017-01-16 23:16
To: yugang
CC: Dave Barach (dbarach); vpp-dev
Subject: Re: [vpp-dev] rte_timer

Have you considered to use process nodes instead?

If you search forvlib_process_suspend and vlib_process_wait_for_event_or_clock 
you will find many samples….

Thanks,

Damjan

On 16 Jan 2017, at 02:13, yug...@telincn.com wrote:

Thanks for your reply, Dave.
I would like to use dpdk timer api in vpp, and i don't know whether  there is a 
substitude.

Here is my code in vpp main func.
rte_timer_subsystem_init();
/* init timer structures */
rte_timer_init(&vpptimer0);
/* load timer0, every second, on master lcore, reloaded automatically */
hz = rte_get_timer_hz();
lcore_id = rte_lcore_id();
rte_timer_reset(&vpptimer0, hz, PERIODICAL, lcore_id, vpp_timer0_cb, NULL);

And i got this Segmentation fault.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x004edde5 in rte_get_hpet_cycles () at 
/usr/src/VPP16/vpp1609/build-root/build-vpp-native/dpdk/dpdk-16.07/lib/librte_eal/linuxapp/eal/eal_timer.c:151
151 t = eal_hpet->counter_l;
Missing separate debuginfos, use: debuginfo-install 
glibc-2.17-157.el7_3.1.x86_64 openssl-libs-1.0.1e-60.el7.x86_64 
zlib-1.2.7-17.el7.x86_64
(gdb) bt
#0  0x004edde5 in rte_get_hpet_cycles () at 
/usr/src/VPP16/vpp1609/build-root/build-vpp-native/dpdk/dpdk-16.07/lib/librte_eal/linuxapp/eal/eal_timer.c:151
#1  0x0050681f in rte_get_timer_cycles () at 
/usr/src/VPP16/vpp1609/build-root/install-vpp-native/dpdk/include/generic/rte_cycles.h:158
#2  rte_timer_reset (tim=tim@entry=0xa73b20 , ticks=ticks@entry=0, 
type=type@entry=PERIODICAL, tim_lcore=4294967295, fct=fct@entry=0x54d9e0 
, arg=arg@entry=0x0)
at 
/usr/src/VPP16/vpp1609/build-root/build-vpp-native/dpdk/dpdk-16.07/lib/librte_timer/rte_timer.c:431
#3  0x0040fe53 in main (argc=26, argv=0xb08810) at 
/usr/src/VPP16/vpp1609/build-data/../vpp/vnet/main.c:271
(gdb) 


yug...@telincn.com
 
From: Dave Barach (dbarach)
Date: 2017-01-15 21:45
To: yug...@telincn.com; vpp-dev
Subject: RE: [vpp-dev] rte_timer
Vpp already calls rte_eal_init(...) in .../src/vnet/dpdk/init.c:dpdk_config(). 
Please don’t call rte_eal_init(..) elsewhere, it simply won’t work.
 
At a higher level: what are you trying to do? It’s hard to provide meaningful 
help with so little information.  
 
Thanks… Dave
 
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of yug...@telincn.com
Sent: Sunday, January 15, 2017 6:38 AM
To: vpp-dev 
Subject: [vpp-dev] rte_timer
 
Hi, all.
If i would like to use dpdk timer, what extra configuration  i need to make?
Since that if i just call func "   rte_eal_init(argc, argv)" in vpp,  it always 
reminds me that there is not enough DPDK mem, why?
 
Regards,
Ewan.


yug...@telincn.com
___
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] Weird VPP API message processing failure

2017-01-16 Thread Jon Loeliger
Folks,

We are seeing a really strange VPP API message processing problem.
The scenario goes like this...

Our CLI issues C API calls through the vlib API.  The messages hit
the shared memory queue, but are not processed.  They sit there.

Later, we fire up, say, vppctl and do a "show api" command.  That
causes the queue to be flushed and the first thing it does is process
the outstanding API messages from our CLI.

This used to work.  About two weeks ago I started pulling in the
top-of-tree stuff to get us closer to development head and get
some of the needed bug fixes.

I'm wondering if this sounds familiar to you at all?

I've started to isolate it with git bisect, and so far I believe the
behavior changed between these commits:

$ git log --oneline
...
553a411 VPP-585: vhost-user interface deletion leaks memory.
ffc18f5 japi: include tests in jar files
738f3f2 API refactoring : dpdk
6bbf83a Revert "vppctl: bash completion for vppctl commands"
842b9c5 Self-service garbage collection for the API message allocator
d995c75 vppctl: bash completion for vppctl commands
0d3c1cc VPP-279: af_packet via Command-line Arg should no longer be
supported
48c1824 Update CSIT tests 170101 -> 170108
...

I've not had a chance to look at them yet, but of those, the most
suspicious looking one to me is:
842b9c5 Self-service garbage collection for the API message allocator

If no one beats me to it, I'll continue bisecting it tomorrow...

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

[vpp-dev] show interface address with multiple tables

2017-01-16 Thread Choonho Son
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 list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [csit-dev] sporadically failing functional tests: L2BD and VXLANoIPv4oVLAN

2017-01-16 Thread Damjan Marion (damarion)

Can we please disable this test temporary as tests are failing?

Thanks,

Damjan


On 16 Jan 2017, at 17:12, Maciek Konstantynowicz (mkonstan) 
mailto:mkons...@cisco.com>> wrote:

Hi, Got the report above are failing from time to time:

https://jenkins.fd.io/job/vpp-csit-verify-virl-master/3316/
https://jenkins.fd.io/job/vpp-csit-verify-virl-master/3316/robot/
https://jenkins.fd.io/job/vpp-csit-verify-virl-master/3313/
https://jenkins.fd.io/job/vpp-csit-verify-virl-master/3312/
https://jenkins.fd.io/job/vpp-csit-verify-virl-master/3311/

Could someone have a look ?

-Maciek

___
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] [csit-dev] crypto-dev support/libraries

2017-01-16 Thread Maciek Konstantynowicz (mkonstan)
//resending with corrected Kirill email

+Ed - known to be able to resolve tricky cross-project build issues.
+vpp-dev - to avoid circular thread references :)

Sergio,

On 11 Jan 2017, at 17:00, Sergio Gonzalez Monroy 
mailto:sergio.gonzalez.mon...@intel.com>> 
wrote:

I'll copy from the thread I started last week, we continue on this one.

OK :)


Basically, when we build VPP with DPDK Cryptodev support 
('vpp_uses_dpdk_cryptodev=yes' at build time) we enable some Cryptodev PMDs 
that are disabled in DPDK by default.
At the moment, the following Crypto PMDs are built:
- QAT PMD: Driver for Intel QuickAssist Technology (QAT) devices.
- AESNI-MB PMD: Software crypto with dependency on 'Intel IPsec Multibuffer 
library'
- AESNI-GCM PMD: Software crypto with dependency on 'Intel IPsec Multibuffer 
library'

The latest 'Intel IPsec Multibuffer' library source code is located in:
https://github.com/01org/intel-ipsec-mb.git

To successfully build DPDK with those PMDs enabled, we previously need to build 
the 'Intel IPsec Multibuffer library' and set up the env variable 
AESNI_MULTI_BUFFER_LIB_PATH.


Today csit-vpp-perf-* jobs use the VPP .deb packages from Nexus.
Based on my (limited) understanding of build systems, this means VPP deb 
package that contains DPDK Cryptodev support needs to be built (using your 
build sequence above) and pushed to Nexus, *before* csit-vpp-perf-* job is 
invoke to run IPSec tests.

Or am I oversimplifying?
If yes - pls correct.
If no - the next step would be to agree on the LF fd.io based job 
implementation to execute above, and I guess it would involve ci-management 
project, or? Ed, can you help us here?

Also FYI, as Jim Thompson noted, we would have at least another library 
dependency with the next DPDK release.

I think you’re referring to this comment by Jim:
There is a pending patch to use ISA-L rather than the Intel IPsec MB lib.
from https://lists.fd.io/pipermail/csit-dev/2017-January/001423.html

This would mean modifying the  'Intel IPsec Multibuffer library’ building step 
while moving to the next DPDK release, yes?

-Maciek

P.S. This thread morphed from the previous one that went dormant:
[csit-dev] VPP with DPDK Cryptodev CSIT IPsec tests
https://lists.fd.io/pipermail/csit-dev/2017-January/001408.html

Sergio

On 11/01/2017 16:04, Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
wrote:
+ Sergio and Kirill

From: csit-dev-boun...@lists.fd.io 
[mailto:csit-dev-boun...@lists.fd.io] On Behalf Of Jan Gelety -X (jgelety - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, January 11, 2017 14:44
To: Damjan Marion (damarion) 
Cc: csit-...@lists.fd.io
Subject: [csit-dev] crypto-dev support/libraries

Hello Damjan,

As shortly mentioned on yesterday’s VPP call – could you, please, give us an 
info how to proceed when we need to test crypto related stuff? Do we need to 
build crypto libraries separately on every machine where the VPP will be run?

Thank you very much.

Regards,
Jan


___
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] [csit-dev] crypto-dev support/libraries

2017-01-16 Thread Maciek Konstantynowicz (mkonstan)
+Ed - known to be able to resolve tricky cross-project build issues.
+vpp-dev - to avoid circular thread references :)

Sergio,

On 11 Jan 2017, at 17:00, Sergio Gonzalez Monroy 
mailto:sergio.gonzalez.mon...@intel.com>> 
wrote:

I'll copy from the thread I started last week, we continue on this one.

OK :)


Basically, when we build VPP with DPDK Cryptodev support 
('vpp_uses_dpdk_cryptodev=yes' at build time) we enable some Cryptodev PMDs 
that are disabled in DPDK by default.
At the moment, the following Crypto PMDs are built:
- QAT PMD: Driver for Intel QuickAssist Technology (QAT) devices.
- AESNI-MB PMD: Software crypto with dependency on 'Intel IPsec Multibuffer 
library'
- AESNI-GCM PMD: Software crypto with dependency on 'Intel IPsec Multibuffer 
library'

The latest 'Intel IPsec Multibuffer' library source code is located in:
https://github.com/01org/intel-ipsec-mb.git

To successfully build DPDK with those PMDs enabled, we previously need to build 
the 'Intel IPsec Multibuffer library' and set up the env variable 
AESNI_MULTI_BUFFER_LIB_PATH.


Today csit-vpp-perf-* jobs use the VPP .deb packages from Nexus.
Based on my (limited) understanding of build systems, this means VPP deb 
package that contains DPDK Cryptodev support needs to be built (using your 
build sequence above) and pushed to Nexus, *before* csit-vpp-perf-* job is 
invoke to run IPSec tests.

Or am I oversimplifying?
If yes - pls correct.
If no - the next step would be to agree on the LF fd.io based job 
implementation to execute above, and I guess it would involve ci-management 
project, or? Ed, can you help us here?

Also FYI, as Jim Thompson noted, we would have at least another library 
dependency with the next DPDK release.

I think you’re referring to this comment by Jim:
There is a pending patch to use ISA-L rather than the Intel IPsec MB lib.
from https://lists.fd.io/pipermail/csit-dev/2017-January/001423.html

This would mean modifying the  'Intel IPsec Multibuffer library’ building step 
while moving to the next DPDK release, yes?

-Maciek

P.S. This thread morphed from the previous one that went dormant:
[csit-dev] VPP with DPDK Cryptodev CSIT IPsec tests
https://lists.fd.io/pipermail/csit-dev/2017-January/001408.html

Sergio

On 11/01/2017 16:04, Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) 
wrote:
+ Sergio and Kirill

From: csit-dev-boun...@lists.fd.io 
[mailto:csit-dev-boun...@lists.fd.io] On Behalf Of Jan Gelety -X (jgelety - 
PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, January 11, 2017 14:44
To: Damjan Marion (damarion) 
Cc: csit-...@lists.fd.io
Subject: [csit-dev] crypto-dev support/libraries

Hello Damjan,

As shortly mentioned on yesterday’s VPP call – could you, please, give us an 
info how to proceed when we need to test crypto related stuff? Do we need to 
build crypto libraries separately on every machine where the VPP will be run?

Thank you very much.

Regards,
Jan


___
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] Avoid constant rebuilding of dpdk during the build process

2017-01-16 Thread Damjan Marion (damarion)

After discussion on the weekly call I improved my patch, and would like to ask 
people
to give it a try and provide feedback.

It is:

https://gerrit.fd.io/r/#/c/4613/

It works as follows:

- If there is no development package (vpp-dpdk-dev (deb)  or vpp-dpdk-devel 
(rpm).
It will just display warning message and compile dpdk like it does today.

 Building dpdk in /home/damarion/cisco/vpp/build-root/build-vpp-native/dpdk 

make[2]: Entering directory '/home/damarion/cisco/vpp/dpdk'
==
Building DPDK from source. Consider installing development
package by invoking 'make dpdk-install-dev' from the
top level directory
==


- Issuing “make dpdk-install-dev” will build deb/rpm inside dpdk/ and install it
  unless there is current version already installed

- if installed version is outdated, following warning will be displayed during 
each build:

make: Entering directory '/home/damarion/cisco/vpp/dpdk'
==
 Outdated DPDK package detected:
  Installed: vpp-dpdk-dev 16.11-vpp0
  Current:   vpp-dpdk-dev 16.11-vpp1

 Please upgrade by invoking 'make dpdk-install-dev'
 from the top level directory.
==
make: Leaving directory '/home/damarion/cisco/vpp/dpdk’


Thanks,

Damjan


> On 10 Jan 2017, at 12:40, Damjan Marion (damarion)  wrote:
> 
> 
> 
> 
>> On 10 Jan 2017, at 11:54, Kinsella, Ray  wrote:
>> 
>> 
>> Seems like a welcome, logical, incremental step towards using DPDK binary 
>> packaging.
>> 
>> Would it make sense to always first try to pull and install the binary 
>> package from the nexus server.
> 
> Yes, absolutely, we are fetching tons of packages anyway (unfortunately).
> 
>> 
>> Only building locally when either the download fails or when forced
>> to do so.
> 
> yep
> 
>> 
>> Then for those people who are developing using a stable release,
>> they save the unnecessary time of building DPDK?
> 
> exactly.
> ___
> 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] rte_timer

2017-01-16 Thread Damjan Marion

Have you considered to use process nodes instead?

If you search forvlib_process_suspend and vlib_process_wait_for_event_or_clock 
you will find many samples….

Thanks,

Damjan

> On 16 Jan 2017, at 02:13, yug...@telincn.com wrote:
> 
> Thanks for your reply, Dave.
> I would like to use dpdk timer api in vpp, and i don't know whether  there is 
> a substitude.
> 
> Here is my code in vpp main func.
> rte_timer_subsystem_init();
>   /* init timer structures */
>   rte_timer_init(&vpptimer0);
>   /* load timer0, every second, on master lcore, reloaded automatically */
>   hz = rte_get_timer_hz();
>   lcore_id = rte_lcore_id();
>   rte_timer_reset(&vpptimer0, hz, PERIODICAL, lcore_id, vpp_timer0_cb, 
> NULL);
> 
> And i got this Segmentation fault.
> 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x004edde5 in rte_get_hpet_cycles () at 
> /usr/src/VPP16/vpp1609/build-root/build-vpp-native/dpdk/dpdk-16.07/lib/librte_eal/linuxapp/eal/eal_timer.c:151
> 151   t = eal_hpet->counter_l;
> Missing separate debuginfos, use: debuginfo-install 
> glibc-2.17-157.el7_3.1.x86_64 openssl-libs-1.0.1e-60.el7.x86_64 
> zlib-1.2.7-17.el7.x86_64
> (gdb) bt
> #0  0x004edde5 in rte_get_hpet_cycles () at 
> /usr/src/VPP16/vpp1609/build-root/build-vpp-native/dpdk/dpdk-16.07/lib/librte_eal/linuxapp/eal/eal_timer.c:151
> #1  0x0050681f in rte_get_timer_cycles () at 
> /usr/src/VPP16/vpp1609/build-root/install-vpp-native/dpdk/include/generic/rte_cycles.h:158
> #2  rte_timer_reset (tim=tim@entry=0xa73b20 , ticks=ticks@entry=0, 
> type=type@entry=PERIODICAL, tim_lcore=4294967295, fct=fct@entry=0x54d9e0 
> , arg=arg@entry=0x0)
> at 
> /usr/src/VPP16/vpp1609/build-root/build-vpp-native/dpdk/dpdk-16.07/lib/librte_timer/rte_timer.c:431
> #3  0x0040fe53 in main (argc=26, argv=0xb08810) at 
> /usr/src/VPP16/vpp1609/build-data/../vpp/vnet/main.c:271
> (gdb) 
> yug...@telincn.com 
>  
> From: Dave Barach (dbarach) 
> Date: 2017-01-15 21:45
> To: yug...@telincn.com ; vpp-dev 
> 
> Subject: RE: [vpp-dev] rte_timer
> Vpp already calls rte_eal_init(...) in 
> .../src/vnet/dpdk/init.c:dpdk_config(). Please don’t call rte_eal_init(..) 
> elsewhere, it simply won’t work. <>
>  
> At a higher level: what are you trying to do? It’s hard to provide meaningful 
> help with so little information.  
>  
> Thanks… Dave
>  
> From: vpp-dev-boun...@lists.fd.io  
> [mailto:vpp-dev-boun...@lists.fd.io ] On 
> Behalf Of yug...@telincn.com 
> Sent: Sunday, January 15, 2017 6:38 AM
> To: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Subject: [vpp-dev] rte_timer
>  
> Hi, all.
> If i would like to use dpdk timer, what extra configuration  i need to make?
> Since that if i just call func "   rte_eal_init(argc, argv)" in vpp,  it 
> always reminds me that there is not enough DPDK mem, why?
>  
> Regards,
> Ewan.
> yug...@telincn.com 
> ___
> 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