[vpp-dev] problems in mips32

2017-03-15 Thread 薛欣颖 

Guys,

I'm looking forward to run vpp in mips32 arch,but problem was caused by 
"clib_calljmp","clib_setjmp" and "clib_longjmp". There is no code for mips32 in 
vpp, so I wrote them by myself, and they worked very well in my test program, 
However,when I run vpp with them, segmentation fault was happend when excute a 
system call like "open","SYS_clock_gettime",etc.

The "stack" in "clib_calljmp" was alloced by "clib_mem_alloc_aligned", It is 
strange that if I did not use "clib_mem_alloc_aligned" but with "malloc", the 
problem is still there but less happened. Sometimes it occurs, but sometimes 
it's ok.

Here is the code I worte for mips32.

uword clib_calljmp (uword (*func) (uword func_arg), uword func_arg, void *stack)
{
 unsigned long ret=0;
 __asm__ volatile (
".set push \n" 
"move $23, $29\n" 
"li   $9, 4\n\t"
"subu $8, %3, $9\n\t"
"sll  $8, $8, 0\n\t"
"move $29, $8\n\t"
"move $9, %1\n\t"  
"move $4, %2\n\t" 
"move $25,$9\n\t"
"move $22, $31\n\t"  
"jalr.hb $25\n\t" 
"nop\n\t"
  "move %0, $2\n\t"
"move $29,$23\n"
"move $31, $22\n\t"   
".set pop\n" 
:"=r"(ret)
:"r"(func),"r"(func_arg),"r"(stack)
:"$8","$9","$23","$22"
);
return ret;
}

Thanks,
Xinying Xue

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

Re: [vpp-dev] Some L2 Bridge API Questions

2017-03-15 Thread Jon Loeliger 
John,

So, I see that, when creating a bridge domain using the API
call bridge_domain_add_del, one can specify some feature
flags of the domain as well as the mac-age parameter.

Later, it looks like one can alter the feature flags using the
API call bridge_flags, changing one or more features to be
enabled or disabled on the fly.

However, it looks like there is no mechanism to alter just
the mac-age parameter.

So, a few questions.  Is one expected to re-issue the bridge
domain "add" request again, with all the same flag-bits, but
with the new mac-age value?  Or is this just a missing API
call that is yet to be added?

In particular, I notice that the code in src/vnet/l2/l2_bd.c has a
command to set a new mac-age, but it doesn't make an API
call to do so; instead it appears to go directly to the underlying
implementation to affect a change.

Any advice here?

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

Re: [vpp-dev] IPsec Multi-Tunnel performance test suite failure

2017-03-15 Thread Sergio Gonzalez Monroy 

I reckon something like the following should do:

enable-cryptodev dev :86:01.0 dev :86:01.1


Sergio


On 15/03/2017 15:36, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at 
Cisco) wrote:


So something like:

enable-cryptodev dev :86:01.0

enable-cryptodev dev :86:02.0

?

*Peter Mikus*
Engineer – Software

*Cisco Systems Limited*

*From:*Sergio Gonzalez Monroy [mailto:sergio.gonzalez.mon...@intel.com]
*Sent:* Wednesday, March 15, 2017 4:14 PM
*To:* Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
; Rybalchenko, Kirill 
; Nicolau, Radu 
*Cc:* Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco) 
; csit-...@lists.fd.io; vpp-dev 
; Maciek Konstantynowicz (mkonstan) 


*Subject:* Re: IPsec Multi-Tunnel performance test suite failure

My bad.

I thought the test was already using two QAT VFs. Each workers needs 
one QAT VF.


Sergio

On 15/03/2017 13:47, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at 
Cisco) wrote:


After I run CSIT with 2 physical cores and 2 worker-threads, the
HW cryptodev is not working:

https://jenkins.fd.io/view/csit/job/csit-vpp-perf-master-all/1178/console

Testing is HW is there was successful and it was initialized.

Can you please take a look?

The only change I did was adding 1 more worker threads.
Initialization remains the same and Cryptodev HW was not recognized?

*Peter Mikus*
Engineer – Software

*Cisco Systems Limited*

*From:*Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco)
*Sent:* Monday, March 13, 2017 2:19 PM
*To:* 'Sergio Gonzalez Monroy' 
; Maciek Konstantynowicz
(mkonstan)  ;
Rybalchenko, Kirill 
; Nicolau, Radu
 
*Cc:* Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco)
 ;
csit-...@lists.fd.io ; vpp-dev
 
*Subject:* RE: IPsec Multi-Tunnel performance test suite failure

+ Looping @csit-dev @vpp-dev

I will add 2 workers/threads that is not a problem.

To avoid possible exploding of number of test, we should pick only
the representative one. Apart from implementation are there any
other differences between tunnel and interface mode?

Thanks.

*Peter Mikus*
Engineer – Software

*Cisco Systems Limited*

*From:*Sergio Gonzalez Monroy
[mailto:sergio.gonzalez.mon...@intel.com]
*Sent:* Monday, March 13, 2017 9:58 AM
*To:* Maciek Konstantynowicz (mkonstan) >; Peter Mikus -X (pmikus - PANTHEON
TECHNOLOGIES at Cisco) >; Rybalchenko, Kirill
>; Nicolau, Radu
>
*Cc:* Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco)
>
*Subject:* Re: IPsec Multi-Tunnel performance test suite failure

First, thank you to all involved!

I reckon those numbers are in the expected range.
The current test is single thread with bidirectional traffic.
I would definitely like to see tests with 2 workers/threads, one
worker for each direction. One of the reasons is that we cannot
saturate QAT with a single worker (QAT should be able to do
+40Gbps of encryption).
Would it make sense to have another set of tests with 2 workers or
just update the current tests to use 2 workers?

Regarding the difference between ipsec interface and tunnels
(a.k.a. SPD), the results are expected.
Basically, it is all about the SPD (Security Policy Database)
implementation. The "tunnels" tests use the SPD, whereas the ipsec
interfaces do not.

The current SPD  implementation in VPP follows the guidelines of
the RFC, but it does not scale.
The ipsec interfaces do not use the SPD at all and a single entry
in the fib is all we need to "select" the traffic to encrypt.
They effectively are different graph node paths, and even though
both end up taking the same amount of cycles (at least for
decryption), the interfaces scale much better.

Sergio

On 11/03/2017 18:36, Maciek Konstantynowicz (mkonstan) wrote:

Great Peter, thanks for this final push !

Sergio, team - are these the results you expect to see?

Why such a difference interfaces vs. tunnels at 1k scale?

aes-gcm interfaces

  1 tunnel1k tunnels

  Mpps

Re: [vpp-dev] IPsec Multi-Tunnel performance test suite failure

2017-03-15 Thread Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
After I run CSIT with 2 physical cores and 2 worker-threads, the HW cryptodev 
is not working:

https://jenkins.fd.io/view/csit/job/csit-vpp-perf-master-all/1178/console

Testing is HW is there was successful and it was initialized.

Can you please take a look?
The only change I did was adding 1 more worker threads. Initialization remains 
the same and Cryptodev HW was not recognized?

Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco)
Sent: Monday, March 13, 2017 2:19 PM
To: 'Sergio Gonzalez Monroy' ; Maciek 
Konstantynowicz (mkonstan) ; Rybalchenko, Kirill 
; Nicolau, Radu 
Cc: Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco) 
; csit-...@lists.fd.io; vpp-dev 
Subject: RE: IPsec Multi-Tunnel performance test suite failure

+ Looping @csit-dev @vpp-dev

I will add 2 workers/threads that is not a problem.

To avoid possible exploding of number of test, we should pick only the 
representative one. Apart from implementation are there any other differences 
between tunnel and interface mode?

Thanks.

Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.mon...@intel.com]
Sent: Monday, March 13, 2017 9:58 AM
To: Maciek Konstantynowicz (mkonstan) 
>; Peter Mikus -X (pmikus - 
PANTHEON TECHNOLOGIES at Cisco) >; 
Rybalchenko, Kirill 
>; Nicolau, 
Radu >
Cc: Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco) 
>
Subject: Re: IPsec Multi-Tunnel performance test suite failure

First, thank you to all involved!

I reckon those numbers are in the expected range.
The current test is single thread with bidirectional traffic.
I would definitely like to see tests with 2 workers/threads, one worker for 
each direction. One of the reasons is that we cannot saturate QAT with a single 
worker (QAT should be able to do +40Gbps of encryption).
Would it make sense to have another set of tests with 2 workers or just update 
the current tests to use 2 workers?

Regarding the difference between ipsec interface and tunnels (a.k.a. SPD), the 
results are expected.
Basically, it is all about the SPD (Security Policy Database) implementation. 
The "tunnels" tests use the SPD, whereas the ipsec interfaces do not.

The current SPD  implementation in VPP follows the guidelines of the RFC, but 
it does not scale.
The ipsec interfaces do not use the SPD at all and a single entry in the fib is 
all we need to "select" the traffic to encrypt.
They effectively are different graph node paths, and even though both end up 
taking the same amount of cycles (at least for decryption), the interfaces 
scale much better.

Sergio

On 11/03/2017 18:36, Maciek Konstantynowicz (mkonstan) wrote:
Great Peter, thanks for this final push !

Sergio, team - are these the results you expect to see?
Why such a difference interfaces vs. tunnels at 1k scale?

aes-gcm interfaces
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 2.5 1.7 2.3 1.5
IMIX2.4 7.1 2.1 6.4
1518B   2.4 28.92.1 26.0

cbc-sha1 interfaces
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 2.5 1.7 2.3 1.5
IMIX2.4 7.2 2.1 6.4
1518B   2.429.2 2.1 29.2

aes-gcm tunnels
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 2.4 1.6 0.4 0.2
IMIX2.4 7.0 0.3 1.0
1518B   2.2 27.80.4 4.3

cbc-sha1 tunnels
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 2.5 1.7 0.4 0.3
IMIX2.4 7.2 0.3 1.0
1518B   2.4 29.20.4 5.0

-Maciek

On 11 Mar 2017, at 06:45, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at 
Cisco) > wrote:

IPSEC is now working. PDR and NDR results are same and can be found there:
https://jenkins.fd.io/view/csit/job/csit-vpp-perf-master-all/1156/console

Plots will be updated to display IPsecHW (seems like wrong xpath eval). I will 
check on Monday.
So far I will run couple more iterations to see the results

@Maciek, I think it is about time to populate all TBs with QAT. Can we 
coordinate?


Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Nicolau, Radu [mailto:radu.nico...@intel.com]
Sent: Wednesday, March 08, 2017 2:07 PM
To: Gonzalez Monroy, Sergio 
>; 
Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
>; Rybalchenko,