date:20170316

Re: [vpp-dev] Missing lib pneum during build?

2017-03-16 Thread Jon Loeliger

On Fri, Mar 10, 2017 at 1:55 PM, Jon Loeliger  wrote:
>
>
> Ole,
>
> I am no fairly confident that this patch fixes the race condition issue
> that I was seeing.
>

Now.  I am now failry confident

And I am still seeing the build failure.  Is there any chance
of getting this patch or a similar fix in place?

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-16 Thread Maciek Konstantynowicz (mkonstan)

Cool - thanks Guys !

-Maciek

On 16 Mar 2017, at 16:18, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at 
Cisco) mailto:pmi...@cisco.com>> wrote:

Compiled numbers from 
https://jenkins.fd.io/view/csit/job/csit-vpp-perf-master-long/1200/console

1t1c

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


2t2c

aes-gcm interfaces
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 4.7 3.1 4.1 2.7
IMIX4.5 13.63.8 11.4
1518B   3.2 39.33.2 39.2
cbc-sha1 interfaces
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 4.9 3.3 4.3 3.5
IMIX4.914.5 4.0 12
1518B   3.542.8 3.5 43.2
aes-gcm tunnels
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 5.0 3.4 0.8 0.5
IMIX4.6 13.70.6 1.8
1518B   3.2 39.20.8 9.4

cbc-sha1 tunnels
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 4.9 3.3 0.8 0.5
IMIX4.7 14.10.3 1.0
1518B   3.5 42.80.8 9.4



Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco)
Sent: Thursday, March 16, 2017 3:13 PM
To: 'Sergio Gonzalez Monroy' 
mailto:sergio.gonzalez.mon...@intel.com>>; 
'Rybalchenko, Kirill' 
mailto:kirill.rybalche...@intel.com>>; 'Nicolau, 
Radu' mailto:radu.nico...@intel.com>>; Maciek 
Konstantynowicz (mkonstan) mailto:mkons...@cisco.com>>
Cc: Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco) 
mailto:tifr...@cisco.com>>; 
'csit-...@lists.fd.io' 
mailto:csit-...@lists.fd.io>>; 'vpp-dev' 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: IPsec Multi-Tunnel performance test suite failure

After fixing few nits with Sergio (thanks for help) looks like we are able to 
measure multicore perf:

https://jenkins.fd.io/view/csit/job/csit-vpp-perf-master-long/1200/console

tc13-64B-2t2c-ethip4ipsecscale1ip4-ip4base-interfaces-aes-gcm-ndrdisc
FINAL_RATE: 4668398.4375 pps (2x 2334199.21875 pps)

This is linear scale if compare with previous 2.5Mpps.

Thanks.

Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco)
Sent: Thursday, March 16, 2017 12:02 PM
To: 'Sergio Gonzalez Monroy' 
mailto:sergio.gonzalez.mon...@intel.com>>; 
Rybalchenko, Kirill 
mailto:kirill.rybalche...@intel.com>>; Nicolau, 
Radu mailto:radu.nico...@intel.com>>
Cc: Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco) 
mailto:tifr...@cisco.com>>; 
csit-...@lists.fd.io; vpp-dev 
mailto:vpp-dev@lists.fd.io>>; Maciek Konstantynowicz 
(mkonstan) mailto:mkons...@cisco.com>>
Subject: RE: IPsec Multi-Tunnel performance test suite failure

I modified the script to produce this config (2 threads):

unix {
  nodaemon
  log /tmp/vpe.log
  cli-listen localhost:5002
  full-coredump
}

api-trace {
  on
}

cpu {
  main-core 19 corelist-workers 20,21
}

dpdk {
  socket-mem 1024,1024
  dev default {
num-rx-queues 1

  }
  dev :88:00.1
  dev :88:00.0
  enable-cryptodev dev :86:01.0 dev :86:01.1
  uio-driver igb_uio
  no-multi-seg
}
ip6 {
  hash-buckets 200
  heap-size 3G
}

I am sure that QAT is initialized with 32VFs (cat 
/sys/bus/pci/devices/\:86\:00.0/sriov_numvfs show 32 on both machines), but:

DUT1 is showing:

vat# vat# DPDK Cryptodev support is disabled

DUT2 is showing:

vat# vat# worker  crypto device id(type)
1 1(HW)
2 0(HW)

The setup for both DUTs is the same. Do you know what may be wrong?

In syslog I do see for both DUTs (lspci shows QAT initialized):

…
Mar 16 01:27:53 t3-sut1 kernel: [94934.751859] uio_pci_generic :86:04.7: 
enabling device ( -> 0002)
Mar 16 01:27:53 t3-sut1 kernel: [94934.751862] uio_pci_generic :86:04.7: No 
IRQ assigned to device: no support for interrupts?

…
Mar 16 01:27:58 t3-sut2 kernel: [94846.606256] uio_pci_generic :86:04.7: 
enabling device ( -> 0002)
Mar 16 01:27:58 t3-sut2 kernel: [94846.606259] uio_pci_generic :86:04.7: No 
IRQ assigned to device: no support for interrupts?

So no more crypto not found.

Any ideas?



Peter Mikus
Engineer – Software
Cisc

Re: [vpp-dev] vhost user and upstream dpdk

2017-03-16 Thread Damjan Marion



> On 16 Mar 2017, at 14:24, Thomas F Herbert  wrote:
> 
> Do we still have a plan convergence toward upstream DPDK for vhost-user?
> 
> This has come up in a discussion in this bugz, 
> https://bugzilla.redhat.com/show_bug.cgi?id=1422534
> 
> and this patch to vhost_user https://gerrit.fd.io/r/#/c/5700/
> 
> --TFH
> 
> 
> 
No, we don't have such plans, i don't see a reason why we would invest 
significant time in adopting 3rd party library if we have own working code.

what is your particular concern?


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

Re: [vpp-dev] problems in mips32

2017-03-16 Thread John Lo (loj)

Thanks for pointing this out, Jon.

This limitation, however, does not prevent bridging from working in 32-bit 
architecture. The API/CLI here for adding IP to MAC address mapping is to be 
used for ARP termination in the bridge domain. So the limitation is that ARP 
termination is not supported for 32-bit architecture. It is an optional feature 
that can be enabled for a bridge domain and is disabled by default.

Regards,
John

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Jon Loeliger
Sent: Thursday, March 16, 2017 12:40 PM
To: Dave Barach (dbarach) 
Cc: vpp-dev 
Subject: Re: [vpp-dev] problems in mips32

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of ???
Sent: Wednesday, March 15, 2017 9:52 PM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] problems in mips32

Guys,

I'm looking forward to run vpp in mips32 arch,but problem was caused by 
"clib_calljmp","clib_setjmp" and "clib_longjmp".
Thanks,
Xinying Xue

Also, be aware that there is a hard-coded limit requiring a 64-bit
uword in the L2 bridge code as well.

Here in src/vnet/l2/l2_bd.c:

/**
 * Add/delete IP address to MAC address mapping.
 *
 * The clib hash implementation stores uword entries in the hash table.
 * The hash table mac_by_ip4 is keyed via IP4 address and store the
 * 6-byte MAC address directly in the hash table entry uword.
 *
 * @warning This only works for 64-bit processor with 8-byte uword;
 * which means this code *WILL NOT WORK* for a 32-bit prcessor with
 * 4-byte uword.
 */
u32
bd_add_del_ip_mac (u32 bd_index,
   u8 * ip_addr, u8 * mac_addr, u8 is_ip6, u8 is_add)

HTH,
jdl

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

Re: [vpp-dev] problems in mips32

2017-03-16 Thread Jon Loeliger

>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *???
>
> *Sent:* Wednesday, March 15, 2017 9:52 PM
> *To:* vpp-dev 
> *Subject:* [vpp-dev] problems in mips32
>
>
>
> Guys,
>
>
>
> I'm looking forward to run vpp in mips32 arch,but
> problem was caused by "clib_calljmp","clib_setjmp" and "clib_longjmp".
>
> Thanks,
>
> Xinying Xue
>

Also, be aware that there is a hard-coded limit requiring a 64-bit
uword in the L2 bridge code as well.

Here in src/vnet/l2/l2_bd.c:

/**
 * Add/delete IP address to MAC address mapping.
 *
 * The clib hash implementation stores uword entries in the hash table.
 * The hash table mac_by_ip4 is keyed via IP4 address and store the
 * 6-byte MAC address directly in the hash table entry uword.
 *
 * @warning This only works for 64-bit processor with 8-byte uword;
 * which means this code *WILL NOT WORK* for a 32-bit prcessor with
 * 4-byte uword.
 */
u32
bd_add_del_ip_mac (u32 bd_index,
   u8 * ip_addr, u8 * mac_addr, u8 is_ip6, u8 is_add)

HTH,
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-16 Thread Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco)

Compiled numbers from 
https://jenkins.fd.io/view/csit/job/csit-vpp-perf-master-long/1200/console

1t1c

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


2t2c

aes-gcm interfaces
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 4.7 3.1 4.1 2.7
IMIX4.5 13.63.8 11.4
1518B   3.2 39.33.2 39.2
cbc-sha1 interfaces
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 4.9 3.3 4.3 3.5
IMIX4.914.5 4.0 12
1518B   3.542.8 3.5 43.2
aes-gcm tunnels
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 5.0 3.4 0.8 0.5
IMIX4.6 13.70.6 1.8
1518B   3.2 39.20.8 9.4

cbc-sha1 tunnels
1 tunnel1k tunnels
MppsGbpsMppsGbps
64B 4.9 3.3 0.8 0.5
IMIX4.7 14.10.3 1.0
1518B   3.5 42.80.8 9.4



Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco)
Sent: Thursday, March 16, 2017 3:13 PM
To: 'Sergio Gonzalez Monroy' ; 'Rybalchenko, 
Kirill' ; 'Nicolau, Radu' 
; Maciek Konstantynowicz (mkonstan) 
Cc: Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco) 
; 'csit-...@lists.fd.io' ; 'vpp-dev' 

Subject: RE: IPsec Multi-Tunnel performance test suite failure

After fixing few nits with Sergio (thanks for help) looks like we are able to 
measure multicore perf:

https://jenkins.fd.io/view/csit/job/csit-vpp-perf-master-long/1200/console

tc13-64B-2t2c-ethip4ipsecscale1ip4-ip4base-interfaces-aes-gcm-ndrdisc
FINAL_RATE: 4668398.4375 pps (2x 2334199.21875 pps)

This is linear scale if compare with previous 2.5Mpps.

Thanks.

Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco)
Sent: Thursday, March 16, 2017 12:02 PM
To: 'Sergio Gonzalez Monroy' 
mailto:sergio.gonzalez.mon...@intel.com>>; 
Rybalchenko, Kirill 
mailto:kirill.rybalche...@intel.com>>; Nicolau, 
Radu mailto:radu.nico...@intel.com>>
Cc: Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco) 
mailto:tifr...@cisco.com>>; 
csit-...@lists.fd.io; vpp-dev 
mailto:vpp-dev@lists.fd.io>>; Maciek Konstantynowicz 
(mkonstan) mailto:mkons...@cisco.com>>
Subject: RE: IPsec Multi-Tunnel performance test suite failure

I modified the script to produce this config (2 threads):

unix {
  nodaemon
  log /tmp/vpe.log
  cli-listen localhost:5002
  full-coredump
}

api-trace {
  on
}

cpu {
  main-core 19 corelist-workers 20,21
}

dpdk {
  socket-mem 1024,1024
  dev default {
num-rx-queues 1

  }
  dev :88:00.1
  dev :88:00.0
  enable-cryptodev dev :86:01.0 dev :86:01.1
  uio-driver igb_uio
  no-multi-seg
}
ip6 {
  hash-buckets 200
  heap-size 3G
}

I am sure that QAT is initialized with 32VFs (cat 
/sys/bus/pci/devices/\:86\:00.0/sriov_numvfs show 32 on both machines), but:

DUT1 is showing:

vat# vat# DPDK Cryptodev support is disabled

DUT2 is showing:

vat# vat# worker  crypto device id(type)
1 1(HW)
2 0(HW)

The setup for both DUTs is the same. Do you know what may be wrong?

In syslog I do see for both DUTs (lspci shows QAT initialized):

…
Mar 16 01:27:53 t3-sut1 kernel: [94934.751859] uio_pci_generic :86:04.7: 
enabling device ( -> 0002)
Mar 16 01:27:53 t3-sut1 kernel: [94934.751862] uio_pci_generic :86:04.7: No 
IRQ assigned to device: no support for interrupts?

…
Mar 16 01:27:58 t3-sut2 kernel: [94846.606256] uio_pci_generic :86:04.7: 
enabling device ( -> 0002)
Mar 16 01:27:58 t3-sut2 kernel: [94846.606259] uio_pci_generic :86:04.7: No 
IRQ assigned to device: no support for interrupts?

So no more crypto not found.

Any ideas?



Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.mon...@intel.com]
Sent: Wednesday, March 15, 2017 5:11 PM
To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
mailto:pmi...@cisco.com>>
Cc: Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco) 
mailto:tifr...@cisco.com>>; 
csit-...@lists.fd.io; vpp-dev 
mailto:vpp-dev@lists.fd.io>>; Ma

Re: [vpp-dev] vpp rpms overlaping files

2017-03-16 Thread otroan

Ed,

> OpNFV has discovered that we have overlapping files in vpp-devel and 
> vpp-python-api
> rpms.  It looks like vpp-python-api is being stuffed into vpp-devel.  Has 
> something changed here recently?

I repackaged python with a commit this morning:
https://gerrit.fd.io/r/#/c/5666/

Did I mess that up? Cause those files shouldn't even be in the Python RPM, they 
are from Java.

Cheers,
Ole


> 
> Ed
> 
> 
> Transaction check error:
>   file /usr/lib/python2.7/site-packages/jvppgen/__init__.py conflicts between 
> attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/__init__.pyc conflicts 
> between attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 
> and vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/__init__.pyo conflicts 
> between attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 
> and vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/callback_gen.py conflicts 
> between attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 
> and vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/callback_gen.pyc conflicts 
> between attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 
> and vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/callback_gen.pyo conflicts 
> between attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 
> and vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/dto_gen.py conflicts between 
> attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/dto_gen.pyc conflicts between 
> attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/dto_gen.pyo conflicts between 
> attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jni_gen.py conflicts between 
> attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jni_gen.pyc conflicts between 
> attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jni_gen.pyo conflicts between 
> attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jvpp_c_gen.py conflicts 
> between attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 
> and vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jvpp_c_gen.pyc conflicts 
> between attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 
> and vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jvpp_c_gen.pyo conflicts 
> between attempted installs of vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 
> and vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jvpp_callback_facade_gen.py 
> conflicts between attempted installs of 
> vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jvpp_callback_facade_gen.pyc 
> conflicts between attempted installs of 
> vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jvpp_callback_facade_gen.pyo 
> conflicts between attempted installs of 
> vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jvpp_future_facade_gen.py 
> conflicts between attempted installs of 
> vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jvpp_future_facade_gen.pyc 
> conflicts between attempted installs of 
> vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-packages/jvppgen/jvpp_future_facade_gen.pyo 
> conflicts between attempted installs of 
> vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and 
> vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
>   file /usr/lib/python2.7/site-pa

[vpp-dev] vpp rpms overlaping files

2017-03-16 Thread Ed Warnicke

OpNFV has discovered that we have overlapping files in vpp-devel and
vpp-python-api
rpms.  It looks like vpp-python-api is being stuffed into vpp-devel.  Has
something changed here recently?

Ed


Transaction check error:
  file /usr/lib/python2.7/site-packages/jvppgen/__init__.py conflicts
between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/__init__.pyc conflicts
between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/__init__.pyo conflicts
between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/callback_gen.py
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/callback_gen.pyc
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/callback_gen.pyo
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/dto_gen.py conflicts
between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/dto_gen.pyc conflicts
between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/dto_gen.pyo conflicts
between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jni_gen.py conflicts
between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jni_gen.pyc conflicts
between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jni_gen.pyo conflicts
between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jvpp_c_gen.py
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jvpp_c_gen.pyc
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jvpp_c_gen.pyo
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jvpp_callback_facade_gen.py
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jvpp_callback_facade_gen.pyc
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jvpp_callback_facade_gen.pyo
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jvpp_future_facade_gen.py
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jvpp_future_facade_gen.pyc
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jvpp_future_facade_gen.pyo
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jvpp_impl_gen.py
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/site-packages/jvppgen/jvpp_impl_gen.pyc
conflicts between attempted installs of
vpp-devel-17.04-rc0~440_ge9f929b~b2064.x86_64 and
vpp-api-python-17.04-rc0~440_ge9f929b~b2064.x86_64
  file /usr/lib/python2.7/s

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

2017-03-16 Thread Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco)

After fixing few nits with Sergio (thanks for help) looks like we are able to 
measure multicore perf:

https://jenkins.fd.io/view/csit/job/csit-vpp-perf-master-long/1200/console

tc13-64B-2t2c-ethip4ipsecscale1ip4-ip4base-interfaces-aes-gcm-ndrdisc
FINAL_RATE: 4668398.4375 pps (2x 2334199.21875 pps)

This is linear scale if compare with previous 2.5Mpps.

Thanks.

Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco)
Sent: Thursday, March 16, 2017 12:02 PM
To: 'Sergio Gonzalez Monroy' ; 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

I modified the script to produce this config (2 threads):

unix {
  nodaemon
  log /tmp/vpe.log
  cli-listen localhost:5002
  full-coredump
}

api-trace {
  on
}

cpu {
  main-core 19 corelist-workers 20,21
}

dpdk {
  socket-mem 1024,1024
  dev default {
num-rx-queues 1

  }
  dev :88:00.1
  dev :88:00.0
  enable-cryptodev dev :86:01.0 dev :86:01.1
  uio-driver igb_uio
  no-multi-seg
}
ip6 {
  hash-buckets 200
  heap-size 3G
}

I am sure that QAT is initialized with 32VFs (cat 
/sys/bus/pci/devices/\:86\:00.0/sriov_numvfs show 32 on both machines), but:

DUT1 is showing:

vat# vat# DPDK Cryptodev support is disabled

DUT2 is showing:

vat# vat# worker  crypto device id(type)
1 1(HW)
2 0(HW)

The setup for both DUTs is the same. Do you know what may be wrong?

In syslog I do see for both DUTs (lspci shows QAT initialized):

…
Mar 16 01:27:53 t3-sut1 kernel: [94934.751859] uio_pci_generic :86:04.7: 
enabling device ( -> 0002)
Mar 16 01:27:53 t3-sut1 kernel: [94934.751862] uio_pci_generic :86:04.7: No 
IRQ assigned to device: no support for interrupts?

…
Mar 16 01:27:58 t3-sut2 kernel: [94846.606256] uio_pci_generic :86:04.7: 
enabling device ( -> 0002)
Mar 16 01:27:58 t3-sut2 kernel: [94846.606259] uio_pci_generic :86:04.7: No 
IRQ assigned to device: no support for interrupts?

So no more crypto not found.

Any ideas?



Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.mon...@intel.com]
Sent: Wednesday, March 15, 2017 5:11 PM
To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
mailto:pmi...@cisco.com>>
Cc: Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco) 
mailto:tifr...@cisco.com>>; 
csit-...@lists.fd.io; vpp-dev 
mailto:vpp-dev@lists.fd.io>>; Maciek Konstantynowicz 
(mkonstan) mailto:mkons...@cisco.com>>; Rybalchenko, Kirill 
mailto:kirill.rybalche...@intel.com>>; Nicolau, 
Radu mailto:radu.nico...@intel.com>>
Subject: Re: IPsec Multi-Tunnel performance test suite failure

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

[vpp-dev] vhost user and upstream dpdk

2017-03-16 Thread Thomas F Herbert


Do we still have a plan convergence toward upstream DPDK for vhost-user?

This has come up in a discussion in this bugz, 
https://bugzilla.redhat.com/show_bug.cgi?id=1422534


and this patch to vhost_user https://gerrit.fd.io/r/#/c/5700/

--TFH


--
*Thomas F Herbert*
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] problems in mips32

2017-03-16 Thread Dave Barach (dbarach)

Please make sure that src/vppinfra/test_longjmp.c passes before you move on. 
You’ve undoubtedly pickled the stack and/or one or more of the registers. 
Clib_calljmp is always the source of subsequent issues.

The code you wrote belongs in longjmp.S. Trying to write clib_calljmp(...) in C 
/ doing the dirty work in an asm volatile makes it all but inevitable that GCC 
will get in the way.

Even though it’s been a long time since I wrote MIPS assembler code: I don’t 
see where you’re saving clib_calljmp’s return address and old stack-pointer on 
the new stack.

If you expect people to even try to help you with assembly code, comments are 
essential.

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of ???
Sent: Wednesday, March 15, 2017 9:52 PM
To: vpp-dev 
Subject: [vpp-dev] problems in mips32


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] Clarification about reflexive ACL jira IDs vpp-514 and vpp-428

2017-03-16 Thread Andrew 👽 Yourtchenko

Hi Padmini,

To me this looks like the same thing indeed.

There is currently support for the reflexive behaviour already in the
L2 switching scenario (if you supply action = 2 in the ACL rules *and*
have the ACL in the opposite direction, then the session lookup is
done before the ACL lookup). The only thing was that I wrote that code
before the interface deletion was available, so I think it won't
cooperate well with that case. Also, in the meantime there were other
infrastructure changes in the meantime, so for the L3+L2 support, I am
making a new, more compact and tighter infra - I plan to first use it
for adding L3 support with IPv6 EH, then after we get it ironed out, I
will rollover the L2 code path to using it as well, and remove the old
infra (I estimate this all should save about a third of the code
size).

If you wanna give a try to the new L3 code early on, give a shout, I
will be happy to put you in the loop - it should be ready by the end
of the week.

--a

On 3/16/17, Padmini  wrote:
> Hi Andrew Yourtchenko,
> I see that you are assigned to vpp-514. Is this the same as
> the vpp-428, which is raised to add the reflexive ACL like feature to VPP.
>
> Thanks and regards
> Padmini
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] problems in mips32

2017-03-16 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

[vpp-dev] Clarification about reflexive ACL jira IDs vpp-514 and vpp-428

2017-03-16 Thread Padmini

Hi Andrew Yourtchenko,
I see that you are assigned to vpp-514. Is this the same as
the vpp-428, which is raised to add the reflexive ACL like feature to VPP.

Thanks and regards
Padmini
___
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-16 Thread Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco)

I modified the script to produce this config (2 threads):

unix {
  nodaemon
  log /tmp/vpe.log
  cli-listen localhost:5002
  full-coredump
}

api-trace {
  on
}

cpu {
  main-core 19 corelist-workers 20,21
}

dpdk {
  socket-mem 1024,1024
  dev default {
num-rx-queues 1

  }
  dev :88:00.1
  dev :88:00.0
  enable-cryptodev dev :86:01.0 dev :86:01.1
  uio-driver igb_uio
  no-multi-seg
}
ip6 {
  hash-buckets 200
  heap-size 3G
}

I am sure that QAT is initialized with 32VFs (cat 
/sys/bus/pci/devices/\:86\:00.0/sriov_numvfs show 32 on both machines), but:

DUT1 is showing:

vat# vat# DPDK Cryptodev support is disabled

DUT2 is showing:

vat# vat# worker  crypto device id(type)
1 1(HW)
2 0(HW)

The setup for both DUTs is the same. Do you know what may be wrong?

In syslog I do see for both DUTs (lspci shows QAT initialized):

…
Mar 16 01:27:53 t3-sut1 kernel: [94934.751859] uio_pci_generic :86:04.7: 
enabling device ( -> 0002)
Mar 16 01:27:53 t3-sut1 kernel: [94934.751862] uio_pci_generic :86:04.7: No 
IRQ assigned to device: no support for interrupts?

…
Mar 16 01:27:58 t3-sut2 kernel: [94846.606256] uio_pci_generic :86:04.7: 
enabling device ( -> 0002)
Mar 16 01:27:58 t3-sut2 kernel: [94846.606259] uio_pci_generic :86:04.7: No 
IRQ assigned to device: no support for interrupts?

So no more crypto not found.

Any ideas?



Peter Mikus
Engineer – Software
Cisco Systems Limited

From: Sergio Gonzalez Monroy [mailto:sergio.gonzalez.mon...@intel.com]
Sent: Wednesday, March 15, 2017 5:11 PM
To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
Cc: Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco) 
; csit-...@lists.fd.io; vpp-dev ; 
Maciek Konstantynowicz (mkonstan) ; Rybalchenko, Kirill 
; Nicolau, Radu 
Subject: Re: IPsec Multi-Tunnel performance test suite failure

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) 
mailto:mkons...@cisco.com>>; Peter Mikus -X (pmikus - 
PANTHEON TECHNOLOGIES at Cisco) mailto:pmi...@cisco.com>>; 
Rybalchenko, Kirill 
mailto:kirill.rybalche...@intel.com>>; Nicolau, 
Radu mailto:radu.nico...@intel.com>>
Cc: Tibor Frank -X (tifrank - PANTHEON TECHNOLOGIES at Cisco) 
mailto:tifr...@cisco.com>>
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

Re: [vpp-dev] Missing lib pneum during build?

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

Re: [vpp-dev] vhost user and upstream dpdk

Re: [vpp-dev] problems in mips32

Re: [vpp-dev] problems in mips32

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

Re: [vpp-dev] vpp rpms overlaping files

[vpp-dev] vpp rpms overlaping files

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

[vpp-dev] vhost user and upstream dpdk

Re: [vpp-dev] problems in mips32

Re: [vpp-dev] Clarification about reflexive ACL jira IDs vpp-514 and vpp-428

[vpp-dev] problems in mips32

[vpp-dev] Clarification about reflexive ACL jira IDs vpp-514 and vpp-428

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

15 matches

Site Navigation

Mail list logo

Footer information