[dpdk-dev] non-x86 ? Re: Would DPDK run on AMD processors

[Irfan Zia]

hi Derek,
   we completed a  DPDK  port onto the Tilera's TILE-GX architecture
'Natively' for a customer. Specifically it was on the Gx-36 (36 Tiles) PCIe
card.   Their  team is able to directly take their Host DPDK apps  (NFV
modules and tunnels generators)  and reuse them on the TileNcore-36 PCIe
card 'as-is',   Allowing them to build their system with much economical
and lower power host CPU (Atom 330).

   we are currently completing similar port for Cavium's OCTEON -II.

   And Yergen is right,  we had to resolve many intriguing technical issues
;-)

-irfan
VP Eng
Paxym Inc.
www.paxym.com


On Fri, Jul 4, 2014 at 4:25 PM, Yerden Zhumabekov 
wrote:

> Intel DPDK is intentionally being developed to bring support of packet
> processing
> to Intel processors. In order to provide high performance in packet
> processing,
> developing Intel DPDK requires rather good optimization, like extensive
> use of
> SSE intrinsics etc. Hence it demands x86 arch.
>
> Since Intel DPDK is opensource, there is no license restriction to run
> it on any arch,
> but I guess one will face rather intriguing technical issues doing that :)
>
> 03.07.2014 19:35, Derek Wasely ?:
> > how about running DPDK on other processors ?   Any licensing restriction
> on using it on non-x86 arch ?  Does it work automatically on say  PPC or
> OCTEON ?
>
> --
> Sincerely,
>
> Yerden Zhumabekov
> STS, ACI
> Astana, KZ
>
>

[dpdk-dev] [PATCH 0/6] Clang compilation support on FreeBSD and Linux

[Bruce Richardson]

This patch set enables clang compilation on FreeBSD and Linux. It includes
patches to fix a number of compilation errors thrown up by clang, and then
adds in the appropriate toolchain makefiles and compile-time configurations.

This set has been tested with clang v3.3 on FreeBSD 10 and clang v3.4 on
Fedora linux 20. The example apps folder has not been tested at this time, this
patch set only focuses on the core libraries and apps.

Bruce Richardson (6):
  pmd_bond: add missing variable initialization
  Makefiles: add clang to compiler if/else block
  mk: Ensure correct detection of SSE4.2 on FreeBSD
  acl: add nmmintrin.h header to allow clang compilation
  mk: add toolchain for clang and linuxapp target
  config: add compile target for clang on BSD

 config/defconfig_x86_64-native-bsdapp-clang   | 71 
 config/defconfig_x86_64-native-linuxapp-clang | 63 ++
 lib/librte_acl/acl_bld.c  |  1 +
 lib/librte_pmd_bond/rte_eth_bond_pmd.c|  2 +-
 lib/librte_pmd_i40e/Makefile  |  9 
 lib/librte_pmd_ixgbe/Makefile |  7 +++
 lib/librte_pmd_vmxnet3/Makefile   |  7 +++
 mk/machine/native/rte.vars.mk | 12 +
 mk/toolchain/clang/rte.toolchain-compat.mk| 43 +++
 mk/toolchain/clang/rte.vars.mk| 77 +++
 10 files changed, 291 insertions(+), 1 deletion(-)
 create mode 100644 config/defconfig_x86_64-native-bsdapp-clang
 create mode 100644 config/defconfig_x86_64-native-linuxapp-clang
 create mode 100644 mk/toolchain/clang/rte.toolchain-compat.mk
 create mode 100644 mk/toolchain/clang/rte.vars.mk

-- 
1.9.3

[dpdk-dev] [PATCH 3/6] mk: Ensure correct detection of SSE4.2 on FreeBSD

[Bruce Richardson]

Add a special case to the native target makefile, where we check if
-march=native shows SSE4.2 support. If it does not, then not everything may
build, so we check if the hardware supports SSE4.2, and use a corei7 target
explicitly to get the SSE4.2 support.

Signed-off-by: Bruce Richardson 
---
 mk/machine/native/rte.vars.mk | 12 
 1 file changed, 12 insertions(+)

diff --git a/mk/machine/native/rte.vars.mk b/mk/machine/native/rte.vars.mk
index da9aa71..f495973 100644
--- a/mk/machine/native/rte.vars.mk
+++ b/mk/machine/native/rte.vars.mk
@@ -56,3 +56,15 @@
 # CPU_ASFLAGS =

 MACHINE_CFLAGS = -march=native
+
+# on FreeBSD systems, sometimes the correct cputype is not picked up.
+# To get everything to compile, we need SSE4.2 support, so check if that is
+# reported by compiler. If not, check if the CPU actually supports it, and if
+# so, set the compilation target to be a corei7, minimum target with SSE4.2
+SSE42_SUPPORT=$(shell $(CC) -march=native -dM -E - < /dev/null | grep SSE4_2)
+ifeq ($(SSE42_SUPPORT),)
+  CPU_SSE42_SUPPORT=$(shell if [ -f /var/run/dmesg.boot ] ; then grep SSE4\.2 
/var/run/dmesg.boot ; fi)
+  ifneq ($(CPU_SSE42_SUPPORT),)
+MACHINE_CFLAGS= -march=corei7
+  endif
+endif
-- 
1.9.3

[dpdk-dev] [PATCH 4/6] acl: add nmmintrin.h header to allow clang compilation

[Bruce Richardson]

Clang compile fails without nmmintrin.h being explicitly included.

Signed-off-by: Bruce Richardson 
---
 lib/librte_acl/acl_bld.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_acl/acl_bld.c b/lib/librte_acl/acl_bld.c
index fe7b824..873447b 100644
--- a/lib/librte_acl/acl_bld.c
+++ b/lib/librte_acl/acl_bld.c
@@ -31,6 +31,7 @@
  *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */

+#include 
 #include 
 #include "tb_mem.h"
 #include "acl.h"
-- 
1.9.3

[dpdk-dev] [PATCH 2/6] Makefiles: add clang to compiler if/else block

[Bruce Richardson]

The makefiles for a number of drivers conditionally disable certain warnings
depending on the compiler and version used. Add in clang to the list of
compiler options.

Signed-off-by: Bruce Richardson 
---
 lib/librte_pmd_i40e/Makefile| 9 +
 lib/librte_pmd_ixgbe/Makefile   | 7 +++
 lib/librte_pmd_vmxnet3/Makefile | 7 +++
 3 files changed, 23 insertions(+)

diff --git a/lib/librte_pmd_i40e/Makefile b/lib/librte_pmd_i40e/Makefile
index 14bce71..4b31675 100644
--- a/lib/librte_pmd_i40e/Makefile
+++ b/lib/librte_pmd_i40e/Makefile
@@ -45,6 +45,15 @@ CFLAGS += $(WERROR_FLAGS)
 #
 ifeq ($(CC), icc)
 CFLAGS_BASE_DRIVER = -wd593
+else ifeq ($(CC), clang)
+CFLAGS_BASE_DRIVER += -Wno-sign-compare
+CFLAGS_BASE_DRIVER += -Wno-unused-value
+CFLAGS_BASE_DRIVER += -Wno-unused-parameter
+CFLAGS_BASE_DRIVER += -Wno-strict-aliasing
+CFLAGS_BASE_DRIVER += -Wno-format
+CFLAGS_BASE_DRIVER += -Wno-missing-field-initializers
+CFLAGS_BASE_DRIVER += -Wno-pointer-to-int-cast
+CFLAGS_BASE_DRIVER += -Wno-format-nonliteral
 else
 CFLAGS_BASE_DRIVER  = -Wno-unused-but-set-variable
 CFLAGS_BASE_DRIVER += -Wno-sign-compare
diff --git a/lib/librte_pmd_ixgbe/Makefile b/lib/librte_pmd_ixgbe/Makefile
index df47715..9278a17 100644
--- a/lib/librte_pmd_ixgbe/Makefile
+++ b/lib/librte_pmd_ixgbe/Makefile
@@ -44,6 +44,13 @@ ifeq ($(CC), icc)
 # CFLAGS for icc
 #
 CFLAGS_BASE_DRIVER = -wd174 -wd593 -wd869 -wd981 -wd2259
+else ifeq ($(CC), clang)
+#
+# CFLAGS for clang
+#
+CFLAGS_BASE_DRIVER = -Wno-unused-parameter -Wno-unused-value
+CFLAGS_BASE_DRIVER += -Wno-strict-aliasing -Wno-format-extra-args
+
 else
 #
 # CFLAGS for gcc
diff --git a/lib/librte_pmd_vmxnet3/Makefile b/lib/librte_pmd_vmxnet3/Makefile
index a44abe1..14726f9 100644
--- a/lib/librte_pmd_vmxnet3/Makefile
+++ b/lib/librte_pmd_vmxnet3/Makefile
@@ -44,6 +44,13 @@ ifeq ($(CC), icc)
 # CFLAGS for icc
 #
 CFLAGS_BASE_DRIVER = -wd174 -wd593 -wd869 -wd981 -wd2259
+else ifeq ($(CC), clang)
+#
+# CFLAGS for clang
+#
+CFLAGS_BASE_DRIVER = -Wno-unused-parameter -Wno-unused-value
+CFLAGS_BASE_DRIVER += -Wno-strict-aliasing -Wno-format-extra-args
+
 else
 #
 # CFLAGS for gcc
-- 
1.9.3

[dpdk-dev] [PATCH 5/6] mk: add toolchain for clang and linuxapp target

[Bruce Richardson]

Add support for clang by adding a toolchain folder for it with the
appropriate files.
Add compilation support for clang on linux by adding a new target.

Signed-off-by: Bruce Richardson 
---
 config/defconfig_x86_64-native-linuxapp-clang | 63 ++
 mk/toolchain/clang/rte.toolchain-compat.mk| 43 +++
 mk/toolchain/clang/rte.vars.mk| 77 +++
 3 files changed, 183 insertions(+)
 create mode 100644 config/defconfig_x86_64-native-linuxapp-clang
 create mode 100644 mk/toolchain/clang/rte.toolchain-compat.mk
 create mode 100644 mk/toolchain/clang/rte.vars.mk

diff --git a/config/defconfig_x86_64-native-linuxapp-clang 
b/config/defconfig_x86_64-native-linuxapp-clang
new file mode 100644
index 000..31f2aa4
--- /dev/null
+++ b/config/defconfig_x86_64-native-linuxapp-clang
@@ -0,0 +1,63 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+
+#include "common_linuxapp"
+
+#
+# machine can define specific variables or action for a specific board
+# RTE_MACHINE can be:
+# default  nothing specific
+# native   current machine
+# atm  Intel?? Atom??? microarchitecture
+# nhm  Intel?? microarchitecture code name Nehalem
+# wsm  Intel?? microarchitecture code name Westmere
+# snb  Intel?? microarchitecture code name Sandy Bridge
+# ivb  Intel?? microarchitecture code name Ivy Bridge
+#
+# Note: if your compiler does not support the relevant -march options,
+# it will be compiled with whatever latest processor the compiler supports!
+#
+CONFIG_RTE_MACHINE="native"
+
+#
+# define the architecture we compile for.
+# CONFIG_RTE_ARCH can be i686, x86_64, x86_64_32
+#
+CONFIG_RTE_ARCH="x86_64"
+CONFIG_RTE_ARCH_X86_64=y
+
+#
+# The compiler we use.
+# Can be gcc or icc.
+#
+CONFIG_RTE_TOOLCHAIN="clang"
+CONFIG_RTE_TOOLCHAIN_CLANG=y
diff --git a/mk/toolchain/clang/rte.toolchain-compat.mk 
b/mk/toolchain/clang/rte.toolchain-compat.mk
new file mode 100644
index 000..862b7df
--- /dev/null
+++ b/mk/toolchain/clang/rte.toolchain-compat.mk
@@ -0,0 +1,43 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDIN

[dpdk-dev] [PATCH 1/6] pmd_bond: add missing variable initialization

[Bruce Richardson]

Variable "valid_slave" wasn't getting properly zero-initialized. This error is
flagged by clang on compile.

Signed-off-by: Bruce Richardson 
---
 lib/librte_pmd_bond/rte_eth_bond_pmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_pmd_bond/rte_eth_bond_pmd.c 
b/lib/librte_pmd_bond/rte_eth_bond_pmd.c
index 048de7f..6ce4e57 100644
--- a/lib/librte_pmd_bond/rte_eth_bond_pmd.c
+++ b/lib/librte_pmd_bond/rte_eth_bond_pmd.c
@@ -920,7 +920,7 @@ bond_ethdev_lsc_event_callback(uint8_t port_id, enum 
rte_eth_event_type type,
struct bond_dev_private *internals;
struct rte_eth_link link;

-   int i, bonded_port_id, valid_slave, active_pos = -1;
+   int i, bonded_port_id, valid_slave = 0, active_pos = -1;

if (type != RTE_ETH_EVENT_INTR_LSC)
return;
-- 
1.9.3

[dpdk-dev] [PATCH 6/6] config: add compile target for clang on BSD

[Bruce Richardson]

Add option to compile on FreeBSD using the clang compiler, now the
default compiler on FreeBSD 10.

Signed-off-by: Bruce Richardson 
---
 config/defconfig_x86_64-native-bsdapp-clang | 71 +
 1 file changed, 71 insertions(+)
 create mode 100644 config/defconfig_x86_64-native-bsdapp-clang

diff --git a/config/defconfig_x86_64-native-bsdapp-clang 
b/config/defconfig_x86_64-native-bsdapp-clang
new file mode 100644
index 000..55c7316
--- /dev/null
+++ b/config/defconfig_x86_64-native-bsdapp-clang
@@ -0,0 +1,71 @@
+#   BSD LICENSE
+#
+#   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+#   All rights reserved.
+#
+#   Redistribution and use in source and binary forms, with or without
+#   modification, are permitted provided that the following conditions
+#   are met:
+#
+# * Redistributions of source code must retain the above copyright
+#   notice, this list of conditions and the following disclaimer.
+# * Redistributions in binary form must reproduce the above copyright
+#   notice, this list of conditions and the following disclaimer in
+#   the documentation and/or other materials provided with the
+#   distribution.
+# * Neither the name of Intel Corporation nor the names of its
+#   contributors may be used to endorse or promote products derived
+#   from this software without specific prior written permission.
+#
+#   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+#   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+#   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+#   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+#   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+#   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+#   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+#   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+#   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+#   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+#   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+
+#include "common_bsdapp"
+
+#
+# define executive environment
+#
+# CONFIG_RTE_EXEC_ENV can be linuxapp, baremetal, bsdapp
+#
+CONFIG_RTE_EXEC_ENV="bsdapp"
+CONFIG_RTE_EXEC_ENV_BSDAPP=y
+
+#
+# machine can define specific variables or action for a specific board
+# RTE_MACHINE can be:
+# default  nothing specific
+# native   current machine
+# atm  Intel?? Atom??? microarchitecture
+# nhm  Intel?? microarchitecture code name Nehalem
+# wsm  Intel?? microarchitecture code name Westmere
+# snb  Intel?? microarchitecture code name Sandy Bridge
+# ivb  Intel?? microarchitecture code name Ivy Bridge
+#
+# Note: if your compiler does not support the relevant -march options,
+# it will be compiled with whatever latest processor the compiler supports!
+#
+CONFIG_RTE_MACHINE="native"
+
+#
+# define the architecture we compile for.
+# CONFIG_RTE_ARCH can be i686, x86_64, x86_64_32
+#
+CONFIG_RTE_ARCH="x86_64"
+CONFIG_RTE_ARCH_X86_64=y
+
+#
+# The compiler we use.
+# Can be gcc or icc.
+#
+CONFIG_RTE_TOOLCHAIN="clang"
+CONFIG_RTE_TOOLCHAIN_CLANG=y
-- 
1.9.3

[dpdk-dev] Performance issue with vmxnet3 pmd

[Patel, Rashmin N]

According to my experiments at moment, the bottleneck lies in backend in 
hypervisor for para-virtual devices including Vmxnet3 and hence different 
front-end drivers (stock Vmxnet3 driver or Vmxnet3-PMD) would performance 
equally well, I don?t have solid numbers to show at moment though. Will update 
you on that.

For now, the main advantage of having DPDK version of Vmxnet3 driver is having 
scalability across multiple hypervisors, and application portability keeping in 
mind that backend can be optimized and higher throughput can be achieved at 
later stage.

Thanks,
Rashmin

From: hyunseok.chang at gmail.com [mailto:hyunseok.ch...@gmail.com] On Behalf 
Of Hyunseok
Sent: Monday, July 07, 2014 4:49 PM
To: Patel, Rashmin N; dev at dpdk.org
Subject: RE: [dpdk-dev] Performance issue with vmxnet3 pmd


Thanks for your response.

I am actually more interested in stock (non-dpdk) vmxnet3 driver vs. vmxnet3 
pmd driver comparison.

When I forward pkts from stock vmxnet3 driver, I am able to achieve much higher 
throughput than with vmxnet3 pmd.  To make comparison fair, I did not leverage 
gro/gso.

Does any of the overheads you mentioned play a role in this comparison?  Here I 
am comparing different drivers for the same vmxnet3 interface...

Regards,
Hyunseok
On Jul 7, 2014 7:03 PM, "Patel, Rashmin N" mailto:rashmin.n.patel at intel.com>> wrote:
Hi Hyunseok,

We should not compare Vmxnet3-PMD with ixgbe-PMD performance as Vmxnet3 device 
is a para-virtual device and it's not similar to directly assigned device to a 
VM either.
There is VMEXIT/VMEXIT occurrence at burst-size boundary and that overhead 
can?t be eliminated unless the design of Vmxnet3 is updated in future. In 
addition to that the packets is being touched in ESXi hypervisor vSwitch layer 
between physical NIC and a virtual machine, which introduces extra overhead, 
which you won't have in case of using Niantic being used natively or passed 
through Vt-d to a virtual machine.

Feature wise, we can compare it to Virtio-PMD solution, but again there is a 
little different in device handling and backend driver support compared to 
Vmxnet3 device so performance comparison won?t to apple to apple.

Thanks,
Rashmin

-Original Message-
From: dev [mailto:dev-bounces at dpdk.org] On 
Behalf Of Hyunseok
Sent: Monday, July 07, 2014 3:22 PM
To: dev at dpdk.org
Subject: [dpdk-dev] Performance issue with vmxnet3 pmd

Hi,

I was testing l2-fwd with vmxnet3 pmd (included in dpdk).

The maximum forwarding rate I got from vmxnet3 pmd with l2fwd is only 2.5 to 
2.8 Gbps.

This is in contrast with ixgbe pmd with which I could easily achieve 10 gbps 
forwarding rate.

With the original vmxnet3 driver (non pmd), I could also achieve close to
10 gpbs with multiple iperf.   But I can never achieve that rate with
vmxnet3 pmd...

So basically vmxnet3 pmd doesn't seem that fast.  Is this a known issue?

Thanks,
-Hyunseok

[dpdk-dev] Tilera Native DPDK. Re: non-x86 ? Re: Would DPDK run on AMD processors

[Irfan Zia]

Derek,

If the customer allows it ; more details could become available.  Meanwhile
it will be their prerogative to contribute.  This is briefly explained at:
http://paxym.com/Paxym_Updates_Multicore_SW.html#DPDK-Native-Tilera-Port

thanks!

-irfan

On Mon, Jul 8, 2014 at 4:46 PM, Derek Wasely  wrote:

can u explain more?  May I test it...what card is needed ?

On Tue, Jul 8, 2014 at 1:06 AM, Irfan Zia  wrote:

>
> hi Derek,
>we completed a  DPDK  port onto the Tilera's TILE-GX architecture
> 'Natively' for a customer. Specifically it was on the Gx-36 (36 Tiles) PCIe
> card.   Their  team is able to directly take their Host DPDK apps  (NFV
> modules and tunnels generators)  and reuse them on the TileNcore-36 PCIe
> card 'as-is',   Allowing them to build their system with much economical
> and lower power host CPU (Atom 330).
>
>we are currently completing similar port for Cavium's OCTEON -II.
>
>And Yerden is right,  we had to resolve many intriguing technical
> issues ;-)
>
> -irfan
> VP Eng
> Paxym Inc.
> www.paxym.com
>
>
> On Fri, Jul 4, 2014 at 4:25 PM, Yerden Zhumabekov 
> wrote:
>
>> Intel DPDK is intentionally being developed to bring support of packet
>> processing
>> to Intel processors. In order to provide high performance in packet
>> processing,
>> developing Intel DPDK requires rather good optimization, like extensive
>> use of
>> SSE intrinsics etc. Hence it demands x86 arch.
>>
>> Since Intel DPDK is opensource, there is no license restriction to run
>> it on any arch,
>> but I guess one will face rather intriguing technical issues doing that :)
>>
>> 03.07.2014 19:35, Derek Wasely ?:
>> > how about running DPDK on other processors ?   Any licensing
>> restriction on using it on non-x86 arch ?  Does it work automatically on
>> say  PPC or OCTEON ?
>>
>> --
>> Sincerely,
>>
>> Yerden Zhumabekov
>> STS, ACI
>> Astana, KZ
>>
>>
>

[dpdk-dev] Build failure on Ubuntu 14.04

[Cao, Waterman]

Thanks Keith.
we will try to enable CentOS in our daily build test.
But I has a little concern about Ubuntu 14.
We enabled latest UB14 with kernel 3.13.0-24 at this may.
It seems that UB LTS will upgrade Linux kernel to 3.13.0-30.
But we don't know when it upgrade, and it will cost a lot of effort to upgrade 
environment.
Can we indicate specific version for Ubuntu 14.04?
Btw, we met the same issue in RedHat 7.0 Beta version.

Waterman

From: Wiles, Roger Keith [mailto:keith.wi...@windriver.com]
Sent: Monday, July 7, 2014 10:42 PM
To: De Lara Guarch, Pablo
Cc: Cao, Waterman; 
Subject: Re: [dpdk-dev] Build failure on Ubuntu 14.04

Someone compiling on CentOS kernel 3.13.7 needed the original code. Looks like 
some other type of ifdef change needs to be done to the kcompat.h file to allow 
it to compile on Ubuntu 14.04 with kernel 3.13.0-30.

Keith Wiles, Principal Technologist with CTO office, Wind River
mobile 972-213-5533

[Powering 30 Years of Innovation]

On Jul 7, 2014, at 3:39 AM, De Lara Guarch, Pablo mailto:pablo.de.lara.guarch at intel.com>> wrote:



Hi Keith,

we built the newest dpdk code on my machine, it seems OK,
please see UB14.04 info in my computer.
System:   Ubuntu14.04
Kernel:   3.13.0-24 X86_64
Compiler: GCC 4.8.2 x86_64

Can you let me know which kernel version you use?

Apparently, it is this one: 3.13.0-30-generic, from uname -a


Thanks
Waterman

[dpdk-dev] Making space in mbuf data-structure

[Zhang, Helin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Monday, July 7, 2014 6:19 PM
> To: Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] Making space in mbuf data-structure
> 
> Hello Bruce,
> 
> Thank you to revive this discussion now that the 1.7 is released.
> 
> First, I would like to reference my previous patch series that first reworks 
> the
> mbuf to gain 9 bytes [1]. The v1 of the patch was discussed at [2].
> 
> Now, let's list what I would find useful to have in this mbuf rework:
> 
> - larger size for ol_flags: this is at least needed for TSO, but as it
>is completely full today, I expect to have this need for other
>features.
> - add other offload fields: l4_len and mss, required for TSO
> - remove ctrl_mbuf: they could be replaced by a packet mbuf. It will
>simplify the mbuf structure. Moreover, it would allow to save room
>in the mbuf.
> - a new vlan tag, I suppose this could be useful in some use-cases
>where vlans are stacked.
> - splitting out fields that are superimposed: if 2 features can be used
>at the same time
> 
> On the other hand, I'm not convinced by this:
> 
> - new filters in the i40e driver: I don't think the mbuf is the
>right place for driver-specific flags. If a feature is brought
>by a new driver requiring a flag in mbuf, we should take care that
>the flag is not bound to this particular driver and would match
>the same feature in another driver.
> - sequence number: I'm not sure I understand the use-case, maybe this
>could stay in a mbuf meta data in the reordering module.
> 
> > Firstly, we believe that there is no possible way that we can ever fit
> > all the fields we need to fit into a 64-byte mbuf, and so we need to
> > start looking at a 128-byte mbuf instead.
> 
> The TSO patches show that it is possible to keep a 64 bytes mbuf (of course, 
> it
> depends on what we want to add in the mbuf). I'm not fundamentally against
> having 128 bytes mbuf. But:
> 
> - it should not be a reason for just adding things and not reworking
>things that could be enhanced
> - it should not be a reason for not optimizing the current mbuf
>structure
> - if we can do the same with a 64 bytes mbuf, we need to carefuly
>compare the solutions as fetching a second cache line is not
>costless in all situations. The 64 bytes solution I'm proposing
>in [1] may cost a bit more in CPU cycles but avoids an additional
>cache prefetch (or miss). In some situations (I'm thinking about
>use-cases where we are memory-bound, e.g. an application processing
>a lot of data), it is better to loose a few CPU cycles.
> 
> > First off the blocks is to look at moving the mempool pointer into the
> > second cache line [...] Beyond this change, I'm also investigating
> > potentially moving the "next"
> > pointer to the second cache line, but it's looking harder to move
> > without serious impact
> 
> I think we can easily find DPDK applications that would use the "next"
> field of the mbuf on rx side, as it is the standard way of chaining packets. 
> For
> instance: IP reassembly, TCP/UDP socket queues, or any other protocol that
> needs a reassembly queue. This is at least what we do in 6WINDGate fast path
> stack, and I suppose other network stack implementations would do something
> similar, so we should probably avoid moving this field to the 2nd cache line.
> 
> One more issue I do foresee, with slower CPUs like Atom, having 2 cache lines
> will add more cost than on Xeon. I'm wondering if it make sense to have a
> compilation time option to select either limited features with one cache line 
> or
> full features 2 line caches. I don't know if it's a good idea because it 
> would make
> the code more complex, but we could consider it. I think we don't target 
> binary
> compatibility today?
> 
>  From a functional point of view, we could check that my TSO patch can be
> adapted to your proposal so we can challenge and merge both approaches.
> 
> As this change would impact the core of DPDK, I think it would be interesting 
> to
> list some representative use-cases in order to evaluate the cost of each
> solution. This will also help for future modifications, and could be included 
> in a
> sort of non-regression test?
> 
> Regards,
> Olivier
> 
> [1] http://dpdk.org/ml/archives/dev/2014-May/002537.html
> [2] http://dpdk.org/ml/archives/dev/2014-May/002322.html

Hi Olivier

I am trying to convince you on the new field of "filter status".
It is for matched Flow Director Filter ID, and might be reused for HASH 
signature if it matches hash filter, or others.
It is quite useful for Flow Director, and not a flag. I guess there should have 
the similar feature even in non-Intel NICs.

Regards,
Helin

[dpdk-dev] Performance issue with vmxnet3 pmd

[Thomas Monjalon]

Hi,

2014-07-07 18:22, Hyunseok:
> I was testing l2-fwd with vmxnet3 pmd (included in dpdk).

Have you tested vmxnet3-usermap (http://dpdk.org/doc/vmxnet3-usermap)?

> The maximum forwarding rate I got from vmxnet3 pmd with l2fwd is only 2.5
> to 2.8 Gbps.

It could be interesting to know your exact testing procedure with numbers for 
vmxnet3-usermap.

Thanks
-- 
Thomas

[dpdk-dev] Making space in mbuf data-structure

[Ivan Boule]

On 07/08/2014 09:04 AM, Zhang, Helin wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
>> Sent: Monday, July 7, 2014 6:19 PM
>> To: Richardson, Bruce; dev at dpdk.org
>> Subject: Re: [dpdk-dev] Making space in mbuf data-structure
>>
>> Hello Bruce,
>>
>> Thank you to revive this discussion now that the 1.7 is released.
>>
>> First, I would like to reference my previous patch series that first reworks 
>> the
>> mbuf to gain 9 bytes [1]. The v1 of the patch was discussed at [2].
>>
>> Now, let's list what I would find useful to have in this mbuf rework:
>>
>> - larger size for ol_flags: this is at least needed for TSO, but as it
>> is completely full today, I expect to have this need for other
>> features.
>> - add other offload fields: l4_len and mss, required for TSO
>> - remove ctrl_mbuf: they could be replaced by a packet mbuf. It will
>> simplify the mbuf structure. Moreover, it would allow to save room
>> in the mbuf.
>> - a new vlan tag, I suppose this could be useful in some use-cases
>> where vlans are stacked.
>> - splitting out fields that are superimposed: if 2 features can be used
>> at the same time
>>
>> On the other hand, I'm not convinced by this:
>>
>> - new filters in the i40e driver: I don't think the mbuf is the
>> right place for driver-specific flags. If a feature is brought
>> by a new driver requiring a flag in mbuf, we should take care that
>> the flag is not bound to this particular driver and would match
>> the same feature in another driver.
>> - sequence number: I'm not sure I understand the use-case, maybe this
>> could stay in a mbuf meta data in the reordering module.
>>
>>> Firstly, we believe that there is no possible way that we can ever fit
>>> all the fields we need to fit into a 64-byte mbuf, and so we need to
>>> start looking at a 128-byte mbuf instead.
>>
>> The TSO patches show that it is possible to keep a 64 bytes mbuf (of course, 
>> it
>> depends on what we want to add in the mbuf). I'm not fundamentally against
>> having 128 bytes mbuf. But:
>>
>> - it should not be a reason for just adding things and not reworking
>> things that could be enhanced
>> - it should not be a reason for not optimizing the current mbuf
>> structure
>> - if we can do the same with a 64 bytes mbuf, we need to carefuly
>> compare the solutions as fetching a second cache line is not
>> costless in all situations. The 64 bytes solution I'm proposing
>> in [1] may cost a bit more in CPU cycles but avoids an additional
>> cache prefetch (or miss). In some situations (I'm thinking about
>> use-cases where we are memory-bound, e.g. an application processing
>> a lot of data), it is better to loose a few CPU cycles.
>>
>>> First off the blocks is to look at moving the mempool pointer into the
>>> second cache line [...] Beyond this change, I'm also investigating
>>> potentially moving the "next"
>>> pointer to the second cache line, but it's looking harder to move
>>> without serious impact
>>
>> I think we can easily find DPDK applications that would use the "next"
>> field of the mbuf on rx side, as it is the standard way of chaining packets. 
>> For
>> instance: IP reassembly, TCP/UDP socket queues, or any other protocol that
>> needs a reassembly queue. This is at least what we do in 6WINDGate fast path
>> stack, and I suppose other network stack implementations would do something
>> similar, so we should probably avoid moving this field to the 2nd cache line.
>>
>> One more issue I do foresee, with slower CPUs like Atom, having 2 cache lines
>> will add more cost than on Xeon. I'm wondering if it make sense to have a
>> compilation time option to select either limited features with one cache 
>> line or
>> full features 2 line caches. I don't know if it's a good idea because it 
>> would make
>> the code more complex, but we could consider it. I think we don't target 
>> binary
>> compatibility today?
>>
>>   From a functional point of view, we could check that my TSO patch can be
>> adapted to your proposal so we can challenge and merge both approaches.
>>
>> As this change would impact the core of DPDK, I think it would be 
>> interesting to
>> list some representative use-cases in order to evaluate the cost of each
>> solution. This will also help for future modifications, and could be 
>> included in a
>> sort of non-regression test?
>>
>> Regards,
>> Olivier
>>
>> [1] http://dpdk.org/ml/archives/dev/2014-May/002537.html
>> [2] http://dpdk.org/ml/archives/dev/2014-May/002322.html
>
> Hi Olivier
>
> I am trying to convince you on the new field of "filter status".
> It is for matched Flow Director Filter ID, and might be reused for HASH 
> signature if it matches hash filter, or others.
> It is quite useful for Flow Director, and not a flag. I guess there should 
> have the similar feature even in non-Intel NICs.
>
By construction, since a packet ca

[dpdk-dev] Making space in mbuf data-structure

[Zhang, Helin]

> -Original Message-
> From: Ivan Boule [mailto:ivan.boule at 6wind.com]
> Sent: Tuesday, July 8, 2014 3:17 PM
> To: Zhang, Helin; Olivier MATZ; Richardson, Bruce
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Making space in mbuf data-structure
> 
> On 07/08/2014 09:04 AM, Zhang, Helin wrote:
> >
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> >> Sent: Monday, July 7, 2014 6:19 PM
> >> To: Richardson, Bruce; dev at dpdk.org
> >> Subject: Re: [dpdk-dev] Making space in mbuf data-structure
> >>
> >> Hello Bruce,
> >>
> >> Thank you to revive this discussion now that the 1.7 is released.
> >>
> >> First, I would like to reference my previous patch series that first
> >> reworks the mbuf to gain 9 bytes [1]. The v1 of the patch was discussed at
> [2].
> >>
> >> Now, let's list what I would find useful to have in this mbuf rework:
> >>
> >> - larger size for ol_flags: this is at least needed for TSO, but as it
> >> is completely full today, I expect to have this need for other
> >> features.
> >> - add other offload fields: l4_len and mss, required for TSO
> >> - remove ctrl_mbuf: they could be replaced by a packet mbuf. It will
> >> simplify the mbuf structure. Moreover, it would allow to save room
> >> in the mbuf.
> >> - a new vlan tag, I suppose this could be useful in some use-cases
> >> where vlans are stacked.
> >> - splitting out fields that are superimposed: if 2 features can be used
> >> at the same time
> >>
> >> On the other hand, I'm not convinced by this:
> >>
> >> - new filters in the i40e driver: I don't think the mbuf is the
> >> right place for driver-specific flags. If a feature is brought
> >> by a new driver requiring a flag in mbuf, we should take care that
> >> the flag is not bound to this particular driver and would match
> >> the same feature in another driver.
> >> - sequence number: I'm not sure I understand the use-case, maybe this
> >> could stay in a mbuf meta data in the reordering module.
> >>
> >>> Firstly, we believe that there is no possible way that we can ever
> >>> fit all the fields we need to fit into a 64-byte mbuf, and so we
> >>> need to start looking at a 128-byte mbuf instead.
> >>
> >> The TSO patches show that it is possible to keep a 64 bytes mbuf (of
> >> course, it depends on what we want to add in the mbuf). I'm not
> >> fundamentally against having 128 bytes mbuf. But:
> >>
> >> - it should not be a reason for just adding things and not reworking
> >> things that could be enhanced
> >> - it should not be a reason for not optimizing the current mbuf
> >> structure
> >> - if we can do the same with a 64 bytes mbuf, we need to carefuly
> >> compare the solutions as fetching a second cache line is not
> >> costless in all situations. The 64 bytes solution I'm proposing
> >> in [1] may cost a bit more in CPU cycles but avoids an additional
> >> cache prefetch (or miss). In some situations (I'm thinking about
> >> use-cases where we are memory-bound, e.g. an application
> processing
> >> a lot of data), it is better to loose a few CPU cycles.
> >>
> >>> First off the blocks is to look at moving the mempool pointer into
> >>> the second cache line [...] Beyond this change, I'm also
> >>> investigating potentially moving the "next"
> >>> pointer to the second cache line, but it's looking harder to move
> >>> without serious impact
> >>
> >> I think we can easily find DPDK applications that would use the "next"
> >> field of the mbuf on rx side, as it is the standard way of chaining
> >> packets. For
> >> instance: IP reassembly, TCP/UDP socket queues, or any other protocol
> >> that needs a reassembly queue. This is at least what we do in
> >> 6WINDGate fast path stack, and I suppose other network stack
> >> implementations would do something similar, so we should probably avoid
> moving this field to the 2nd cache line.
> >>
> >> One more issue I do foresee, with slower CPUs like Atom, having 2
> >> cache lines will add more cost than on Xeon. I'm wondering if it make
> >> sense to have a compilation time option to select either limited
> >> features with one cache line or full features 2 line caches. I don't
> >> know if it's a good idea because it would make the code more complex,
> >> but we could consider it. I think we don't target binary compatibility 
> >> today?
> >>
> >>   From a functional point of view, we could check that my TSO patch
> >> can be adapted to your proposal so we can challenge and merge both
> approaches.
> >>
> >> As this change would impact the core of DPDK, I think it would be
> >> interesting to list some representative use-cases in order to
> >> evaluate the cost of each solution. This will also help for future
> >> modifications, and could be included in a sort of non-regression test?
> >>
> >> Regards,
> >> Olivier
> >>
> >> [1] http://dpdk.org/ml/archives/dev/2014-May/002537.html
> >

[dpdk-dev] [PATCH] eal/linuxapp: Add parameter to specify master lcore id

[Simon Kuenzer]

This commit enables users to specify the lcore id that
is used as master lcore.

Signed-off-by: Simon Kuenzer 
---
 lib/librte_eal/linuxapp/eal/eal.c |   33 +
 1 file changed, 33 insertions(+)

diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
b/lib/librte_eal/linuxapp/eal/eal.c
index 573fd06..4ad5b9b 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -101,6 +101,7 @@
 #define OPT_XEN_DOM0"xen-dom0"
 #define OPT_CREATE_UIO_DEV "create-uio-dev"
 #define OPT_VFIO_INTR"vfio-intr"
+#define OPT_MASTER_LCORE "master-lcore"

 #define RTE_EAL_BLACKLIST_SIZE 0x100

@@ -336,6 +337,7 @@ eal_usage(const char *prgname)
   "[--proc-type primary|secondary|auto] \n\n"
   "EAL options:\n"
   "  -c COREMASK  : A hexadecimal bitmask of cores to run on\n"
+  "  --"OPT_MASTER_LCORE" ID: Core ID that is used as master\n"
   "  -n NUM   : Number of memory channels\n"
   "  -v   : Display version information on startup\n"
   "  -d LIB.so: add driver (can be used multiple times)\n"
@@ -468,6 +470,21 @@ eal_parse_coremask(const char *coremask)
return 0;
 }

+/* Changes the lcore id of the master thread */
+static int
+eal_parse_master_lcore(const char *arg)
+{
+   struct rte_config *cfg = rte_eal_get_configuration();
+   int master_lcore = atoi(arg);
+
+   if (!(master_lcore >= 0 && master_lcore < RTE_MAX_LCORE))
+   return -1;
+   if (cfg->lcore_role[master_lcore] != ROLE_RTE)
+   return -1;
+   cfg->master_lcore = master_lcore;
+   return 0;
+}
+
 static int
 eal_parse_syslog(const char *facility)
 {
@@ -653,6 +670,7 @@ eal_parse_args(int argc, char **argv)
{OPT_HUGE_DIR, 1, 0, 0},
{OPT_NO_SHCONF, 0, 0, 0},
{OPT_PROC_TYPE, 1, 0, 0},
+   {OPT_MASTER_LCORE, 1, 0, 0},
{OPT_FILE_PREFIX, 1, 0, 0},
{OPT_SOCKET_MEM, 1, 0, 0},
{OPT_PCI_WHITELIST, 1, 0, 0},
@@ -802,6 +820,21 @@ eal_parse_args(int argc, char **argv)
else if (!strcmp(lgopts[option_index].name, 
OPT_PROC_TYPE)) {
internal_config.process_type = 
eal_parse_proc_type(optarg);
}
+   else if (!strcmp(lgopts[option_index].name, 
OPT_MASTER_LCORE)) {
+   if (!coremask_ok) {
+   RTE_LOG(ERR, EAL, "please specify the 
master "
+   "lcore id after 
specifying "
+   "the coremask\n");
+   eal_usage(prgname);
+   return -1;
+   }
+   if (eal_parse_master_lcore(optarg) < 0) {
+   RTE_LOG(ERR, EAL, "invalid parameter 
for --"
+   OPT_MASTER_LCORE "\n");
+   eal_usage(prgname);
+   return -1;
+   }
+   }
else if (!strcmp(lgopts[option_index].name, 
OPT_FILE_PREFIX)) {
internal_config.hugefile_prefix = optarg;
}
-- 
1.7.10.4

[dpdk-dev] [PATCH] eal/linuxapp: Add parameter to specify master lcore id

[Simon Kuenzer]

Here are some comments about the use case of this patch:

This patch is especially useful in cases where DPDK applications scale 
their CPU resources at runtime via starting and stopping slave lcores. 
Since the coremask defines the maximum scale-out for such a application, 
the master lcore becomes to the minimum scale-in.
Imagine, running multiple primary processed of such DPDK applications, 
users might want to overlap the coremasks for scaling. However, it would 
still make sense to run the master lcores on different CPU cores.

In DPDK vSwitch we might end up in such a scenario with a future release:
   https://lists.01.org/pipermail/dpdk-ovs/2014-March/000770.html
   https://lists.01.org/pipermail/dpdk-ovs/2014-March/000773.html

Thanks,

Simon

On 08.07.2014 10:28, Simon Kuenzer wrote:
> This commit enables users to specify the lcore id that
> is used as master lcore.
>
> Signed-off-by: Simon Kuenzer 
> ---
>   lib/librte_eal/linuxapp/eal/eal.c |   33 +
>   1 file changed, 33 insertions(+)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal.c 
> b/lib/librte_eal/linuxapp/eal/eal.c
> index 573fd06..4ad5b9b 100644
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -101,6 +101,7 @@
>   #define OPT_XEN_DOM0"xen-dom0"
>   #define OPT_CREATE_UIO_DEV "create-uio-dev"
>   #define OPT_VFIO_INTR"vfio-intr"
> +#define OPT_MASTER_LCORE "master-lcore"
>
>   #define RTE_EAL_BLACKLIST_SIZE  0x100
>
> @@ -336,6 +337,7 @@ eal_usage(const char *prgname)
>  "[--proc-type primary|secondary|auto] \n\n"
>  "EAL options:\n"
>  "  -c COREMASK  : A hexadecimal bitmask of cores to run on\n"
> +"  --"OPT_MASTER_LCORE" ID: Core ID that is used as master\n"
>  "  -n NUM   : Number of memory channels\n"
>  "  -v   : Display version information on startup\n"
>  "  -d LIB.so: add driver (can be used multiple times)\n"
> @@ -468,6 +470,21 @@ eal_parse_coremask(const char *coremask)
>   return 0;
>   }
>
> +/* Changes the lcore id of the master thread */
> +static int
> +eal_parse_master_lcore(const char *arg)
> +{
> + struct rte_config *cfg = rte_eal_get_configuration();
> + int master_lcore = atoi(arg);
> +
> + if (!(master_lcore >= 0 && master_lcore < RTE_MAX_LCORE))
> + return -1;
> + if (cfg->lcore_role[master_lcore] != ROLE_RTE)
> + return -1;
> + cfg->master_lcore = master_lcore;
> + return 0;
> +}
> +
>   static int
>   eal_parse_syslog(const char *facility)
>   {
> @@ -653,6 +670,7 @@ eal_parse_args(int argc, char **argv)
>   {OPT_HUGE_DIR, 1, 0, 0},
>   {OPT_NO_SHCONF, 0, 0, 0},
>   {OPT_PROC_TYPE, 1, 0, 0},
> + {OPT_MASTER_LCORE, 1, 0, 0},
>   {OPT_FILE_PREFIX, 1, 0, 0},
>   {OPT_SOCKET_MEM, 1, 0, 0},
>   {OPT_PCI_WHITELIST, 1, 0, 0},
> @@ -802,6 +820,21 @@ eal_parse_args(int argc, char **argv)
>   else if (!strcmp(lgopts[option_index].name, 
> OPT_PROC_TYPE)) {
>   internal_config.process_type = 
> eal_parse_proc_type(optarg);
>   }
> + else if (!strcmp(lgopts[option_index].name, 
> OPT_MASTER_LCORE)) {
> + if (!coremask_ok) {
> + RTE_LOG(ERR, EAL, "please specify the 
> master "
> + "lcore id after 
> specifying "
> + "the coremask\n");
> + eal_usage(prgname);
> + return -1;
> + }
> + if (eal_parse_master_lcore(optarg) < 0) {
> + RTE_LOG(ERR, EAL, "invalid parameter 
> for --"
> + OPT_MASTER_LCORE "\n");
> + eal_usage(prgname);
> + return -1;
> + }
> + }
>   else if (!strcmp(lgopts[option_index].name, 
> OPT_FILE_PREFIX)) {
>   internal_config.hugefile_prefix = optarg;
>   }
>

[dpdk-dev] [PATCH] Added Spinlock to l3fwd-vf example to prevent race conditioning

[Daniel Mrzyglod]

Signed-off-by: Daniel Mrzyglod 
---
 examples/l3fwd-vf/main.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/examples/l3fwd-vf/main.c b/examples/l3fwd-vf/main.c
index 2ca5c21..57852d0 100644
--- a/examples/l3fwd-vf/main.c
+++ b/examples/l3fwd-vf/main.c
@@ -54,6 +54,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -328,7 +329,7 @@ struct lcore_conf {
 } __rte_cache_aligned;

 static struct lcore_conf lcore_conf[RTE_MAX_LCORE];
-
+static rte_spinlock_t 
spinlock_conf[RTE_MAX_ETHPORTS]={RTE_SPINLOCK_INITIALIZER};
 /* Send burst of packets on an output interface */
 static inline int
 send_burst(struct lcore_conf *qconf, uint16_t n, uint8_t port)
@@ -340,7 +341,10 @@ send_burst(struct lcore_conf *qconf, uint16_t n, uint8_t 
port)
queueid = qconf->tx_queue_id;
m_table = (struct rte_mbuf **)qconf->tx_mbufs[port].m_table;

+   rte_spinlock_lock(&spinlock_conf[port]) ;
ret = rte_eth_tx_burst(port, queueid, m_table, n);
+   rte_spinlock_unlock(&spinlock_conf[port]);
+   
if (unlikely(ret < n)) {
do {
rte_pktmbuf_free(m_table[ret]);
-- 
1.7.9.5

[dpdk-dev] Build failure on Ubuntu 14.04

[Wiles, Roger Keith]

Here is the release information I have, if you want more let me know.

$sudo apt-get update
$sudo apt-get upgrade

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04 LTS
Release:14.04
Codename:   trusty

$ uname -a
Linux keithw-W2600CR 3.13.0-30-generic #55-Ubuntu SMP Fri Jul 4 21:40:53 UTC 
2014 x86_64 x86_64 x86_64 GNU/Linux

$ gcc --version
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 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.

Keith Wiles, Principal Technologist with CTO office, Wind River
mobile 972-213-5533

[Powering 30 Years of Innovation]

On Jul 7, 2014, at 9:12 PM, Cao, Waterman mailto:waterman.cao at intel.com>> wrote:

Thanks Keith.
we will try to enable CentOS in our daily build test.
But I has a little concern about Ubuntu 14.
We enabled latest UB14 with kernel 3.13.0-24 at this may.
It seems that UB LTS will upgrade Linux kernel to 3.13.0-30.
But we don?t know when it upgrade, and it will cost a lot of effort to upgrade 
environment.
Can we indicate specific version for Ubuntu 14.04?
Btw, we met the same issue in RedHat 7.0 Beta version.

Waterman

From: Wiles, Roger Keith [mailto:keith.wi...@windriver.com]
Sent: Monday, July 7, 2014 10:42 PM
To: De Lara Guarch, Pablo
Cc: Cao, Waterman; mailto:dev at dpdk.org>>
Subject: Re: [dpdk-dev] Build failure on Ubuntu 14.04

Someone compiling on CentOS kernel 3.13.7 needed the original code. Looks like 
some other type of ifdef change needs to be done to the kcompat.h file to allow 
it to compile on Ubuntu 14.04 with kernel 3.13.0-30.

Keith Wiles, Principal Technologist with CTO office, Wind River
mobile 972-213-5533

[Powering 30 Years of Innovation]

On Jul 7, 2014, at 3:39 AM, De Lara Guarch, Pablo mailto:pablo.de.lara.guarch at intel.com>> wrote:



Hi Keith,

we built the newest dpdk code on my machine, it seems OK,
please see UB14.04 info in my computer.
System:   Ubuntu14.04
Kernel:   3.13.0-24 X86_64
Compiler: GCC 4.8.2 x86_64

Can you let me know which kernel version you use?

Apparently, it is this one: 3.13.0-30-generic, from uname -a


Thanks
Waterman

[dpdk-dev] Performance issue with vmxnet3 pmd

[Hyunseok]

Thomas,

The last time I tried vmxnet3-usermap a couple of weeks ago, it did not
compile against the latest kernel (3.11).  Is it still the case?  Or do you
have the latest version which is compatible with newer kernels?

Also, do you have any benchmark numbers with vmxnet3-usermap in any chance?

Regards,
-Hyunseok




On Tue, Jul 8, 2014 at 3:05 AM, Thomas Monjalon 
wrote:

> Hi,
>
> 2014-07-07 18:22, Hyunseok:
> > I was testing l2-fwd with vmxnet3 pmd (included in dpdk).
>
> Have you tested vmxnet3-usermap (http://dpdk.org/doc/vmxnet3-usermap)?
>
> > The maximum forwarding rate I got from vmxnet3 pmd with l2fwd is only 2.5
> > to 2.8 Gbps.
>
> It could be interesting to know your exact testing procedure with numbers
> for
> vmxnet3-usermap.
>
> Thanks
> --
> Thomas
>

[dpdk-dev] Setup script for xen ?

[Gary M]

Hi,

New to the dpdk and just downloaded 1.7.  I attempting to execute the test
application (17) in Dom0 through the setup script.

It hangs during or just after setting up memory. I know I'm doing something
wrong, I just can't quickly figure out it is.. need some help !!

I have UIO and KNI modules loaded and 64 pages NUMA shared memory. (I also
tried 64 pages non-numa with the same result.)

See:
Option: 17


  Enter hex bitmask of cores to execute test app on
  Example: to execute app on cores 0 to 7, enter 0xff
bitmask: 0x01
Launching app
EAL: Detected lcore 0 as core 1 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 2 on socket 0
EAL: Detected lcore 4 as core 3 on socket 0
EAL: Detected lcore 5 as core 3 on socket 0
EAL: Detected lcore 6 as core 4 on socket 0
EAL: Detected lcore 7 as core 4 on socket 0
EAL: Support maximum 64 logical core(s) by configuration.
EAL: Detected 8 lcore(s)
EAL:   unsupported IOMMU type!
EAL: VFIO support could not be initialized
EAL: Setting up memory...


Using debian jessie 3.14-1-amd64 #1 SMP Debian 3.14.4-1 (2014-05-13) x86_64
GNU/Linux  with XEN 4.3.0

Any suggestions ?

-gary

[dpdk-dev] 32 bit virtio_pmd pkt i/o issue

[Vijayakumar Muthuvel Manickam]

Hi,


I am using 32bit VIRTIO PMD from dpdk-1.6.0r1 and seeing a basic packet I/O
issue under some VM configurations when testing with l2fwd application.

The issue is that Tx on virtio NIC is not working. Packets enqueued by
virtio pmd on Tx queue are not dequeued by the backend vhost-net for some
reason.

I confirmed this after seeing that the RX counter on the corresponding
vnetx interface on the KVM host is zero.

As a result, after enqueuing the first 128(half of 256 total size) packets
the Tx queue becomes full and no more packets can be enqueued.

Each packet using 2 descriptors in the Tx queue allows 128 packets to be
enqueued.



The issue is not seen when using 64bit l2fwd application that uses 64 bit
virtio pmd.


With 32bit l2fwd application I see this issue for some combination of core
and RAM allocated to the VM, but works in other cases as below:


Failure cases:

8 cores and 16G/12G RAM allocated to VM



Some of the Working cases:

8 cores and 8G/9G/10G/11G/13G allocated to VM

2 cores and any RAM allocation including 16G&12G

One more observation is:
By default I reserve 128 2MB hugepages for DPDK. After seeing the above
failure scenario, if I just kill l2fwd and reduce the number of hugepages
to 64 with the command,


echo 64 >  /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages


the same l2fwd app starts working. I believe the issue has something to do
with the physical memzone virtqueue is allocated each time.




I am using igb_uio.ko built from x86_64-default-linuxapp-gcc config and

all other dpdk libs built from i686-default-linuxapp-gcc.

This is because my kernel is 64bit and my application is 32 bit.



Below are the details of my setup:



Linux kernel : 2.6.32-220.el6.x86_64

DPDK version : dpdk-1.6.0r1

Hugepages : 128 2MB hugepages

DPDK Binaries used:

*  64bit igb_uio.ko

* 32bit l2fwd application


I'd appreciate if you could give me some pointers on debugging the issue ?


Thanks,
Vijay