[dpdk-dev] [PATCH] i40evf: fix the issue of configuring rss key enable flags

[Helin Zhang]

It fixes the issue of not configuring rss key enable flags
when there is no rss key available.

Fixes: 647d1eaf758b ("i40evf: support AQ based RSS config")

Signed-off-by: Helin Zhang 
---
 drivers/net/i40e/i40e_ethdev_vf.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index ea96f85..5c554f2 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2200,9 +2200,14 @@ i40evf_set_rss_key(struct i40e_vsi *vsi, uint8_t *key, 
uint8_t key_len)
struct i40e_hw *hw = I40E_VSI_TO_HW(vsi);
int ret = 0;

-   if (!key || key_len != ((I40E_VFQF_HKEY_MAX_INDEX + 1) *
-   sizeof(uint32_t)))
+   if (!key || key_len == 0) {
+   PMD_DRV_LOG(DEBUG, "No key to be configured");
+   return 0;
+   } else if (key_len != (I40E_VFQF_HKEY_MAX_INDEX + 1) *
+   sizeof(uint32_t)) {
+   PMD_DRV_LOG(ERR, "Invalid key length %u", key_len);
return -EINVAL;
+   }

if (vf->flags & I40E_FLAG_RSS_AQ_CAPABLE) {
struct i40e_aqc_get_set_rss_key_data *key_dw =
@@ -2322,12 +2327,14 @@ i40evf_config_rss(struct i40e_vf *vf)
return 0;
}

-   if (rss_conf.rss_key == NULL || rss_conf.rss_key_len < nb_q) {
+   if (rss_conf.rss_key == NULL || rss_conf.rss_key_len <
+   (I40E_VFQF_HKEY_MAX_INDEX + 1) * sizeof(uint32_t)) {
/* Calculate the default hash key */
for (i = 0; i <= I40E_VFQF_HKEY_MAX_INDEX; i++)
rss_key_default[i] = (uint32_t)rte_rand();
rss_conf.rss_key = (uint8_t *)rss_key_default;
-   rss_conf.rss_key_len = nb_q;
+   rss_conf.rss_key_len = (I40E_VFQF_HKEY_MAX_INDEX + 1) *
+   sizeof(uint32_t);
}

return i40evf_hw_rss_hash_set(vf, _conf);
-- 
1.9.3

[dpdk-dev] [PATCH 1/2 v2] examples/distributor: Fix compile issue

[Thomas Monjalon]

> > examples/distributor/main.c(338): error #167:
> > argument of type "struct rte_mbuf *"
> > is incompatible with parameter of type "const char *"
> > _mm_prefetch(bufs[0], 0);
> > 
> > The first param pass to _mm_prefetch is wrong,
> > need convert "struct rte_mbuf *" to "void *".
> > 
> > Fixes: 07db4a975094 ("examples/distributor: new sample app")
> > 
> > Signed-off-by: Michael Qiu 
> 
> Acked-by: Pablo de Lara 

As described by Pablo, it is seen with ICC 2015.

Series applied, thanks

[dpdk-dev] [PATCH 7/7] mk: Add hierarchy-file support (linux mod)

[Arevalo, Mario Alfredo C]

Hi ferruh,

thank you for your comments in this serie of patches :) , I have been
working on different new patches version in order to improve them according
to feedback from different developers, at this moment I have sent the version 6
I would like to know your point of view and the point of view from more 
developers about it :)
this is the link where you can see the 6 version:

http://dpdk.org/ml/archives/dev/2015-November/027988.html

Thank you.
Mario.

From: dev [dev-bounces at dpdk.org] on behalf of Ferruh Yigit 
[ferruh.yi...@intel.com]
Sent: Friday, November 27, 2015 8:01 AM
To: Thomas Monjalon
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 7/7] mk: Add hierarchy-file support  (linux  
mod)

On Fri, Nov 27, 2015 at 04:40:51PM +0100, Thomas Monjalon wrote:
> 2015-09-22 09:56, Panu Matilainen:
> > On 09/18/2015 11:33 PM, Mario Carrillo wrote:
> > > +MOD_DIR := $(DESTDIR)/lib/modules
> > > +KERNEL_DIR := $(shell uname -r)/extra
> >
> > Please don't assume one is always building for the running kernel.
> > Defaulting around uname -r is perfectly reasonable, but there needs to
> > be a way to override it from the cli. For example rte.vars.mk has this:
> >
> > # can be overriden by make command line or exported environment variable
> > RTE_KERNELDIR ?= /lib/modules/$(shell uname -r)/build
>
> For info, the ?= operator is a way to give a default value after having
> included other makefiles which may set a different value.
> Both ?= and := (or simply =) are overriden by the command line.
> Only "override VAR =" will not be overriden by the command line.
>

As far as I know only "?=" assignment overridden by command line.

Basic experiment:

# cat Makefile
A ?= a
B := b
C = c

all:
@echo $(A) $(B) $(C)

-

# make
a b c

# A=x B=x C=x make
x b c


ferruh

[dpdk-dev] [PATCH v2] fm10k: add debug info for actual Rx/Tx func

[Thomas Monjalon]

2015-11-27 09:54, Chen Jing D:
> From: "Chen Jing D(Mark)" 
> 
> After introducing vPMD feature, fm10k driver will select best
> Rx/Tx in running time. Original implementation selects Rx/Tx
> silently without notifications.
> 
> This patch adds debug info to notify user what actual Rx/Tx
> func are used.
> 
> Signed-off-by: Chen Jing D(Mark) 

Applied, thanks

[dpdk-dev] [PATCH] fm10k: fix wrong Rx func is used

[Thomas Monjalon]

2015-11-27 09:55, Chen Jing D:
> From: "Chen Jing D(Mark)" 
> 
> Steps to reproduce the bug:
> 1. All Rx offloading is disabled and start the device, then
>Vector Rx is used.
> 2. Stop the device. Re-configure to enable hw_ip_checksum = 1,
>start the device again.
> 3. In this case, assume regular Rx should be used since Vector
>Rx doesn't support ip checksum offload. But actually Vector
>Rx is used and cause checksum won't be done by hardware.
> 
> The reason is after re-configuring, driver misses an "else" in
> func fm10k_set_rx_function(). Then Rx func in last round are
> used.
> 
> Fixes:77a8ab47("fm10k: select best Rx function")

git log -1 --abbrev=12 --format='Fixes: %h ("%s")' 77a8ab47
Fixes: 77a8ab47eb38 ("fm10k: select best Rx function")

> Reported-by: Xiao Wang 
> Signed-off-by: Chen Jing D(Mark) 
Acked-by: Xiao Wang 

Applied, thanks

[dpdk-dev] [PATCH] e1000: fix VF mac address issue

[Thomas Monjalon]

2015-11-27 14:07, Wenzhuo Lu:
> If use DPDK PF + DPDK VF on igb NICs, we find the MAC address of VF
> port is always 0. Because we forget to give it a value if this MAC
> address is not assigned by PF. This patch'll assign a random MAC
> address to igb VF port as ixgbe does.
> 
> Signed-off-by: Wenzhuo Lu 

Applied with an entry in the release notes, thanks

[dpdk-dev] [PATCH] i40evf: fix the issue of configuring rss key enable flags

[Thomas Monjalon]

2015-11-27 23:34, Helin Zhang:
> It fixes the issue of not configuring rss key enable flags
> when there is no rss key available.
> 
> Fixes: 647d1eaf758b ("i40evf: support AQ based RSS config")
> 
> Signed-off-by: Helin Zhang 

Applied, thanks

[dpdk-dev] [PATCH v3 1/2] app/test: fix failures in the ring_pmd_autotest program

[Thomas Monjalon]

2015-11-27 16:40, Iremonger, Bernard:
> Will correct in v4.

Bernard, please use --in-reply-to 
'<1448640460-25249-1-git-send-email-bernard.iremonger at intel.com>'.
It will thread the v4 below the v3.
Thanks

[dpdk-dev] [PATCH] cryptodev: fixes for gcc 4.4.7 build issues

[Thomas Monjalon]

2015-11-27 17:44, Declan Doherty:
> - Fix for build error caused by flexible array member in struct 
> rte_ccryptodev_session.

error: flexible array member in otherwise empty struct

> - Change void** casting of sess parameter in rte_cryptodev_session_create 
> which
> causes a strict-aliasing error

Fixes: d11b0f30df88 ("cryptodev: introduce API and framework for crypto 
devices")

> Signed-off-by: Declan Doherty 

Applied, thanks

[dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm

[Jerin Jacob]

Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
does support only SSE intrinsic, so disable it till we have neon support.

Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")

Signed-off-by: Jerin Jacob 
---
 config/common_arm64  | 1 +
 config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
 2 files changed, 2 insertions(+)

diff --git a/config/common_arm64 b/config/common_arm64
index 5e5e303..d6a9cb9 100644
--- a/config/common_arm64
+++ b/config/common_arm64
@@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
 CONFIG_RTE_LIBRTE_LPM=n
 CONFIG_RTE_LIBRTE_TABLE=n
 CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_SCHED_VECTOR=n
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index 82143af..9924ff9 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n
 CONFIG_RTE_LIBRTE_LPM=n
 CONFIG_RTE_LIBRTE_TABLE=n
 CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_SCHED_VECTOR=n

 # cannot use those on ARM
 CONFIG_RTE_KNI_KMOD=n
-- 
2.1.0

[dpdk-dev] [PATCH v3 1/2] config: arm64: create common arm64 configs under common_arm64 file

[Jerin Jacob]

let  each armv8 machine targets  capture only the differences
between the common arm64 config.

Suggested-by: Thomas Monjalon 
Signed-off-by: Jerin Jacob 
---
 config/common_arm64  | 48 
 config/defconfig_arm64-armv8a-linuxapp-gcc   | 18 +--
 config/defconfig_arm64-thunderx-linuxapp-gcc | 18 +--
 config/defconfig_arm64-xgene1-linuxapp-gcc   | 18 +--
 4 files changed, 51 insertions(+), 51 deletions(-)
 create mode 100644 config/common_arm64

diff --git a/config/common_arm64 b/config/common_arm64
new file mode 100644
index 000..5e5e303
--- /dev/null
+++ b/config/common_arm64
@@ -0,0 +1,48 @@
+#   BSD LICENSE
+#
+#   Copyright (C) Cavium networks 2015. 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 Cavium networks 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.
+#
+
+
+CONFIG_RTE_ARCH="arm64"
+CONFIG_RTE_ARCH_ARM64=y
+CONFIG_RTE_ARCH_64=y
+CONFIG_RTE_ARCH_ARM_NEON=y
+
+CONFIG_RTE_FORCE_INTRINSICS=y
+
+CONFIG_RTE_IXGBE_INC_VECTOR=n
+CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
+CONFIG_RTE_LIBRTE_IVSHMEM=n
+CONFIG_RTE_LIBRTE_FM10K_PMD=n
+CONFIG_RTE_LIBRTE_I40E_PMD=n
+
+CONFIG_RTE_LIBRTE_LPM=n
+CONFIG_RTE_LIBRTE_TABLE=n
+CONFIG_RTE_LIBRTE_PIPELINE=n
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 49e7056..39e36b8 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -30,27 +30,11 @@
 #

 #include "common_linuxapp"
+#include "common_arm64"

 CONFIG_RTE_MACHINE="armv8a"

-CONFIG_RTE_ARCH="arm64"
-CONFIG_RTE_ARCH_ARM64=y
-CONFIG_RTE_ARCH_64=y
-CONFIG_RTE_ARCH_ARM_NEON=y
-
-CONFIG_RTE_FORCE_INTRINSICS=y
-
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y

 CONFIG_RTE_CACHE_LINE_SIZE=64
-
-CONFIG_RTE_IXGBE_INC_VECTOR=n
-CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
-CONFIG_RTE_LIBRTE_IVSHMEM=n
-CONFIG_RTE_LIBRTE_FM10K_PMD=n
-CONFIG_RTE_LIBRTE_I40E_PMD=n
-
-CONFIG_RTE_LIBRTE_LPM=n
-CONFIG_RTE_LIBRTE_TABLE=n
-CONFIG_RTE_LIBRTE_PIPELINE=n
diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc 
b/config/defconfig_arm64-thunderx-linuxapp-gcc
index 6b2048b..d63d9b8 100644
--- a/config/defconfig_arm64-thunderx-linuxapp-gcc
+++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
@@ -30,27 +30,11 @@
 #

 #include "common_linuxapp"
+#include "common_arm64"

 CONFIG_RTE_MACHINE="thunderx"

-CONFIG_RTE_ARCH="arm64"
-CONFIG_RTE_ARCH_ARM64=y
-CONFIG_RTE_ARCH_64=y
-CONFIG_RTE_ARCH_ARM_NEON=y
-
-CONFIG_RTE_FORCE_INTRINSICS=y
-
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y

 CONFIG_RTE_CACHE_LINE_SIZE=128
-
-CONFIG_RTE_IXGBE_INC_VECTOR=n
-CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
-CONFIG_RTE_LIBRTE_IVSHMEM=n
-CONFIG_RTE_LIBRTE_FM10K_PMD=n
-CONFIG_RTE_LIBRTE_I40E_PMD=n
-
-CONFIG_RTE_LIBRTE_LPM=n
-CONFIG_RTE_LIBRTE_TABLE=n
-CONFIG_RTE_LIBRTE_PIPELINE=n
diff --git a/config/defconfig_arm64-xgene1-linuxapp-gcc 
b/config/defconfig_arm64-xgene1-linuxapp-gcc
index d75f8f0..0759721 100644
--- a/config/defconfig_arm64-xgene1-linuxapp-gcc
+++ b/config/defconfig_arm64-xgene1-linuxapp-gcc
@@ -30,27 +30,11 @@
 #

 #include "common_linuxapp"
+#include "common_arm64"

 CONFIG_RTE_MACHINE="xgene1"

-CONFIG_RTE_ARCH="arm64"
-CONFIG_RTE_ARCH_ARM64=y
-CONFIG_RTE_ARCH_64=y
-CONFIG_RTE_ARCH_ARM_NEON=y
-
-CONFIG_RTE_FORCE_INTRINSICS=y
-
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y

 CONFIG_RTE_CACHE_LINE_SIZE=64
-
-CONFIG_RTE_IXGBE_INC_VECTOR=n
-CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
-CONFIG_RTE_LIBRTE_IVSHMEM=n

[dpdk-dev] [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm

[Jerin Jacob]

v1..v2
created common arm64 configs under common_arm64 file.
let  each armv8 machine targets  capture only the differences
between the common arm64 config.

v2..v3
Fix whitespace issue with git am

Jerin Jacob (2):
  config: arm64: create common arm64 configs under common_arm64 file
  config: disable CONFIG_RTE_SCHED_VECTOR for arm

 config/common_arm64  | 49 
 config/defconfig_arm-armv7a-linuxapp-gcc |  1 +
 config/defconfig_arm64-armv8a-linuxapp-gcc   | 18 +-
 config/defconfig_arm64-thunderx-linuxapp-gcc | 18 +-
 config/defconfig_arm64-xgene1-linuxapp-gcc   | 18 +-
 5 files changed, 53 insertions(+), 51 deletions(-)
 create mode 100644 config/common_arm64

-- 
2.1.0

[dpdk-dev] [PATCH] reserve 'make install' for future use

[Thomas Monjalon]

2015-11-25 10:48, Panu Matilainen:
> On 11/24/2015 06:54 PM, Bruce Richardson wrote:
> > On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote:
> >> 2015-11-06 12:57, Bruce Richardson:
> >>> So, any thoughts or comments on this? There has been lots of discussion 
> >>> in this
> >>> general area but nothing yet going into the release to try and improve 
> >>> the situation.
> >>>
> >>> Are we just going to kick the problem down the road to the 2.3 release?
> >>
> >> I plan to check these patches in the coming days for an integration in 2.2.
> >>
> > Anything further on this?
> > Any thoughts from anyone else about this whole area of a saner build/install
> > system for DPDK and the various patches floating around.
> 
> Well, it seems we wont have a sane "make install" in 2.2 yet, but this 
> is at least a step in the right direction so +1 from me.

Why is it a step in the right direction?

We just need to install the files in a different hierarchy and adapt
the makefiles to be able to compile an application while keeping the
RTE_SDK variable to specify the root directory (previously built thanks
to DESTDIR).
As the hierarchy could be tuned, we need more variables, e.g.:
DPDK_INC_DIR (default = RTE_SDK/include/dpdk)
DPDK_LIB_DIR (default = RTE_SDK/lib)

While doing it, we can have a specific handling of T= to keep compatibility
with the current (old) syntax.

What have I missed?

[dpdk-dev] [PATCH v2 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm

[Jerin Jacob]

Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
does support only SSE intrinsic, so disable it till we have neon support.

Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")

Signed-off-by: Jerin Jacob 
---
 config/common_arm64  | 1 +
 config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
 2 files changed, 2 insertions(+)

diff --git a/config/common_arm64 b/config/common_arm64
index c1e27e2..e211ff4 100644
--- a/config/common_arm64
+++ b/config/common_arm64
@@ -46,4 +46,5 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
 CONFIG_RTE_LIBRTE_LPM=n
 CONFIG_RTE_LIBRTE_TABLE=n
 CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_SCHED_VECTOR=n

diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index 82143af..9924ff9 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n
 CONFIG_RTE_LIBRTE_LPM=n
 CONFIG_RTE_LIBRTE_TABLE=n
 CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_SCHED_VECTOR=n

 # cannot use those on ARM
 CONFIG_RTE_KNI_KMOD=n
-- 
2.1.0

[dpdk-dev] [PATCH v2 1/2] config: arm64: create common arm64 configs under common_arm64 file

[Jerin Jacob]

let  each armv8 machine targets  capture only the differences
between the common arm64 config.

Suggested-by:  Thomas Monjalon 
Signed-off-by: Jerin Jacob 
---
 config/common_arm64  | 49 
 config/defconfig_arm64-armv8a-linuxapp-gcc   | 17 +-
 config/defconfig_arm64-thunderx-linuxapp-gcc | 18 +-
 config/defconfig_arm64-xgene1-linuxapp-gcc   | 17 +-
 4 files changed, 52 insertions(+), 49 deletions(-)
 create mode 100644 config/common_arm64

diff --git a/config/common_arm64 b/config/common_arm64
new file mode 100644
index 000..c1e27e2
--- /dev/null
+++ b/config/common_arm64
@@ -0,0 +1,49 @@
+#   BSD LICENSE
+#
+#   Copyright (C) Cavium networks 2015. 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 Cavium networks 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.
+#
+
+
+CONFIG_RTE_ARCH="arm64"
+CONFIG_RTE_ARCH_ARM64=y
+CONFIG_RTE_ARCH_64=y
+CONFIG_RTE_ARCH_ARM_NEON=y
+
+CONFIG_RTE_FORCE_INTRINSICS=y
+
+CONFIG_RTE_IXGBE_INC_VECTOR=n
+CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
+CONFIG_RTE_LIBRTE_IVSHMEM=n
+CONFIG_RTE_LIBRTE_FM10K_PMD=n
+CONFIG_RTE_LIBRTE_I40E_PMD=n
+
+CONFIG_RTE_LIBRTE_LPM=n
+CONFIG_RTE_LIBRTE_TABLE=n
+CONFIG_RTE_LIBRTE_PIPELINE=n
+
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 49e7056..74b4154 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -30,27 +30,12 @@
 #

 #include "common_linuxapp"
+#include "common_arm64"

 CONFIG_RTE_MACHINE="armv8a"

-CONFIG_RTE_ARCH="arm64"
-CONFIG_RTE_ARCH_ARM64=y
-CONFIG_RTE_ARCH_64=y
-CONFIG_RTE_ARCH_ARM_NEON=y
-
-CONFIG_RTE_FORCE_INTRINSICS=y
-
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y

 CONFIG_RTE_CACHE_LINE_SIZE=64

-CONFIG_RTE_IXGBE_INC_VECTOR=n
-CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
-CONFIG_RTE_LIBRTE_IVSHMEM=n
-CONFIG_RTE_LIBRTE_FM10K_PMD=n
-CONFIG_RTE_LIBRTE_I40E_PMD=n
-
-CONFIG_RTE_LIBRTE_LPM=n
-CONFIG_RTE_LIBRTE_TABLE=n
-CONFIG_RTE_LIBRTE_PIPELINE=n
diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc 
b/config/defconfig_arm64-thunderx-linuxapp-gcc
index 6b2048b..eef5993 100644
--- a/config/defconfig_arm64-thunderx-linuxapp-gcc
+++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
@@ -30,27 +30,11 @@
 #

 #include "common_linuxapp"
+#include "common_arm64"

 CONFIG_RTE_MACHINE="thunderx"

-CONFIG_RTE_ARCH="arm64"
-CONFIG_RTE_ARCH_ARM64=y
-CONFIG_RTE_ARCH_64=y
-CONFIG_RTE_ARCH_ARM_NEON=y
-
-CONFIG_RTE_FORCE_INTRINSICS=y
-
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y
-
 CONFIG_RTE_CACHE_LINE_SIZE=128

-CONFIG_RTE_IXGBE_INC_VECTOR=n
-CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
-CONFIG_RTE_LIBRTE_IVSHMEM=n
-CONFIG_RTE_LIBRTE_FM10K_PMD=n
-CONFIG_RTE_LIBRTE_I40E_PMD=n
-
-CONFIG_RTE_LIBRTE_LPM=n
-CONFIG_RTE_LIBRTE_TABLE=n
-CONFIG_RTE_LIBRTE_PIPELINE=n
diff --git a/config/defconfig_arm64-xgene1-linuxapp-gcc 
b/config/defconfig_arm64-xgene1-linuxapp-gcc
index d75f8f0..b158237 100644
--- a/config/defconfig_arm64-xgene1-linuxapp-gcc
+++ b/config/defconfig_arm64-xgene1-linuxapp-gcc
@@ -30,27 +30,12 @@
 #

 #include "common_linuxapp"
+#include "common_arm64"

 CONFIG_RTE_MACHINE="xgene1"

-CONFIG_RTE_ARCH="arm64"
-CONFIG_RTE_ARCH_ARM64=y
-CONFIG_RTE_ARCH_64=y
-CONFIG_RTE_ARCH_ARM_NEON=y
-
-CONFIG_RTE_FORCE_INTRINSICS=y
-
 CONFIG_RTE_TOOLCHAIN="gcc"
 CONFIG_RTE_TOOLCHAIN_GCC=y

 CONFIG_RTE_CACHE_LINE_SIZE=64

-CONFIG_RTE_IXGBE_INC_VECTOR=n
-CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
-CONFIG_RTE_LIBRTE_IVSHMEM=n

[dpdk-dev] [PATCH v2 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm

[Jerin Jacob]

v1..v2
created common arm64 configs under common_arm64 file.
let  each armv8 machine targets  capture only the differences
between the common arm64 config.

Jerin Jacob (2):
  config: arm64: create common arm64 configs under common_arm64 file
  config: disable CONFIG_RTE_SCHED_VECTOR for arm

 config/common_arm64  | 50 
 config/defconfig_arm-armv7a-linuxapp-gcc |  1 +
 config/defconfig_arm64-armv8a-linuxapp-gcc   | 17 +-
 config/defconfig_arm64-thunderx-linuxapp-gcc | 18 +-
 config/defconfig_arm64-xgene1-linuxapp-gcc   | 17 +-
 5 files changed, 54 insertions(+), 49 deletions(-)
 create mode 100644 config/common_arm64

-- 
2.1.0

[dpdk-dev] [PATCH] cryptodev: fixes for gcc 4.4.7 build issues

[Declan Doherty]

- Fix for build error caused by flexible array member in struct 
rte_ccryptodev_session.
- Change void** casting of sess parameter in rte_cryptodev_session_create which
causes a strict-aliasing error

Signed-off-by: Declan Doherty 
---
 lib/librte_cryptodev/rte_cryptodev.c | 7 +--
 lib/librte_cryptodev/rte_cryptodev_pmd.h | 2 +-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/lib/librte_cryptodev/rte_cryptodev.c 
b/lib/librte_cryptodev/rte_cryptodev.c
index edd1320..f09f67e 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -1037,6 +1037,7 @@ rte_cryptodev_session_create(uint8_t dev_id, struct 
rte_crypto_xform *xform)
 {
struct rte_cryptodev *dev;
struct rte_cryptodev_session *sess;
+   void *_sess;

if (!rte_cryptodev_pmd_is_valid_dev(dev_id)) {
CDEV_LOG_ERR("Invalid dev_id=%d", dev_id);
@@ -1046,11 +1047,13 @@ rte_cryptodev_session_create(uint8_t dev_id, struct 
rte_crypto_xform *xform)
dev = _crypto_devices[dev_id];

/* Allocate a session structure from the session pool */
-   if (rte_mempool_get(dev->data->session_pool, (void **))) {
+   if (rte_mempool_get(dev->data->session_pool, &_sess)) {
CDEV_LOG_ERR("Couldn't get object from session mempool");
return NULL;
}

+   sess = (struct rte_cryptodev_session *)_sess;
+
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->session_configure, NULL);
if (dev->dev_ops->session_configure(dev, xform, sess->_private) ==
NULL) {
@@ -1058,7 +1061,7 @@ rte_cryptodev_session_create(uint8_t dev_id, struct 
rte_crypto_xform *xform)
dev_id);

/* Return session to mempool */
-   rte_mempool_put(sess->mp, (void *)sess);
+   rte_mempool_put(sess->mp, _sess);
return NULL;
}

diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h 
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index d5fbe44..8270afa 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -76,7 +76,7 @@ struct rte_cryptodev_session {
struct rte_mempool *mp;
} __rte_aligned(8);

-   char _private[];
+   char _private[0];
 };

 struct rte_cryptodev_driver;
-- 
2.5.0

[dpdk-dev] [PATCH 7/7] mk: Add hierarchy-file support (linux mod)

[David Marchand]

On Fri, Nov 27, 2015 at 5:01 PM, Ferruh Yigit 
wrote:

> As far as I know only "?=" assignment overridden by command line.
>
> Basic experiment:
>
> # cat Makefile
> A ?= a
> B := b
> C = c
>
> all:
> @echo $(A) $(B) $(C)
>
> -
>
> # make
> a b c
>
> # A=x B=x C=x make
> x b c
>

Those variables are passed through env, but if you give them to make.

$ make A=x B=x C=x
x x x


-- 
David Marchand

[dpdk-dev] [PATCH v3 6/8] mk: Add rule for installing nic bind files

[Thomas Monjalon]

2015-10-02 10:54, Richardson, Bruce:
> I think there are better utilities available for determining the core layout
> that cpu_layout.py. "lstopo", for one, is much more powerful. Do we want/need
> to keep our own script around for that?

Good question.
Anyone against dropping cpu_layout.py?

[dpdk-dev] [PATCH 7/7] mk: Add hierarchy-file support (linux mod)

[Ferruh Yigit]

On Fri, Nov 27, 2015 at 04:23:07PM +, Bruce Richardson wrote:
> On Fri, Nov 27, 2015 at 05:20:43PM +0100, David Marchand wrote:
> > On Fri, Nov 27, 2015 at 5:01 PM, Ferruh Yigit 
> > wrote:
> > 
> > > As far as I know only "?=" assignment overridden by command line.
> > >
> > > Basic experiment:
> > >
> > > # cat Makefile
> > > A ?= a
> > > B := b
> > > C = c
> > >
> > > all:
> > > @echo $(A) $(B) $(C)
> > >
> > > -
> > >
> > > # make
> > > a b c
> > >
> > > # A=x B=x C=x make
> > > x b c
> > >
> > 
> > Those variables are passed through env, but if you give them to make.
> > 
> > $ make A=x B=x C=x
> > x x x
> > 
> >
> You just beat me to it! ?= can be overridden by either environment or 
> cmdline, others
> are overridden just by cmdline, which means they are passed to make, not to 
> the
> shell.
> 
I see, thanks for clarification.

ferruh

[dpdk-dev] [PATCH 7/7] mk: Add hierarchy-file support (linux mod)

[Thomas Monjalon]

2015-09-22 09:56, Panu Matilainen:
> On 09/18/2015 11:33 PM, Mario Carrillo wrote:
> > +MOD_DIR := $(DESTDIR)/lib/modules
> > +KERNEL_DIR := $(shell uname -r)/extra
> 
> Please don't assume one is always building for the running kernel. 
> Defaulting around uname -r is perfectly reasonable, but there needs to 
> be a way to override it from the cli. For example rte.vars.mk has this:
> 
> # can be overriden by make command line or exported environment variable
> RTE_KERNELDIR ?= /lib/modules/$(shell uname -r)/build

For info, the ?= operator is a way to give a default value after having
included other makefiles which may set a different value.
Both ?= and := (or simply =) are overriden by the command line.
Only "override VAR =" will not be overriden by the command line.

[dpdk-dev] [PATCH v3 1/2] app/test: fix failures in the ring_pmd_autotest program

[Iremonger, Bernard]

Hi Bruce,


> Subject: Re: [dpdk-dev] [PATCH v3 1/2] app/test: fix failures in the
> ring_pmd_autotest program
> 
> On Fri, Nov 27, 2015 at 04:07:39PM +, Bernard Iremonger wrote:
> > If eth_ring vdevs are created from the command line with the --vdev
> > option, they create there own rings which are not shared by other vdevs.
> 
> Typo: s/their/there/

Will correct in v4.

> 
> > Some of tests in this suite require that the vdevs share rings, so
> > some of the tests fail.
> >
> > For vdevs to share rings they must be created in the test code with
> > the
> > rte_eth_from_rings() function using rings created with the
> > rte_ring_create() function.
> >
> > Use the command line option --vdev=eth_ring0 to create port 0.
> 
> As I understand it, this option is not mandatory for the tests to pass, it 
> only
> allows some additional functional tests on cmd-line created rings to be run.
> This should perhaps still be called out in the commit message.

I will add that this option is not mandatory to the commit message.

> 
> > Create two rings and five ethdevs in test_pmd_ring.c for ports 1 to 5.
> "... and then use these to run the unit tests on the pmd ring functionality"
> 
> 
> > Improve test output by adding the port number to printf statements,
> > and adding a printf describing each test.
> >
> 
> /Bruce

Regards,

Bernard.

[dpdk-dev] [PATCH 7/7] mk: Add hierarchy-file support (linux mod)

[Bruce Richardson]

On Fri, Nov 27, 2015 at 05:20:43PM +0100, David Marchand wrote:
> On Fri, Nov 27, 2015 at 5:01 PM, Ferruh Yigit 
> wrote:
> 
> > As far as I know only "?=" assignment overridden by command line.
> >
> > Basic experiment:
> >
> > # cat Makefile
> > A ?= a
> > B := b
> > C = c
> >
> > all:
> > @echo $(A) $(B) $(C)
> >
> > -
> >
> > # make
> > a b c
> >
> > # A=x B=x C=x make
> > x b c
> >
> 
> Those variables are passed through env, but if you give them to make.
> 
> $ make A=x B=x C=x
> x x x
> 
>
You just beat me to it! ?= can be overridden by either environment or cmdline, 
others
are overridden just by cmdline, which means they are passed to make, not to the
shell.

/Bruce

[dpdk-dev] [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4

[Ananyev, Konstantin]

> -Original Message-
> From: Qiu, Michael
> Sent: Friday, November 27, 2015 3:22 PM
> To: Ananyev, Konstantin
> Cc: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4
> 
> Sorry for not explaining clearly.
> 
> For gcc version start from version 4.4, x86intrin.h will be include, and 
> inside x86intrin.h, immintrin.h will be directly include without
> check AVX

Yes, but inside immintrin.h there is a check.
At least that what I am seeing for gcc4.4.3:

#ifdef __AVX__
#include 
#endif

Isn't it the same for your case? 
Konstantin

> (as I know, AVX is not exist when gcc >= 4.4),so no AVX macro does not mean 
> vector disable.
> 
> Only gcc < 4.4 and no macro AVX will disable vector.
> 
> This is my understanding, may be wrong :)
> 
> Thanks,
> Michael
> 
> > ? 2015?11?2710:09?Ananyev, Konstantin  
> > ???
> >
> >
> >
> >> -Original Message-
> >> From: Qiu, Michael
> >> Sent: Friday, November 27, 2015 2:02 PM
> >> To: Ananyev, Konstantin
> >> Cc: Thomas Monjalon; dev at dpdk.org
> >> Subject: Re: [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4
> >>
> >> I just replied that Marco AVX only exist in gcc version < 4.4 , otherwise 
> >> it will not exist.
> >
> > If macro __AVX__ not defined, then
> > #if defined(__AVX__)
> > would always be false and SCHED_VECTOR_ENABLE also wouldn't be defined.
> > So still don't understand why that is a problem
> > Konstantin
> >
> >>
> >> What's your suggest will not work if gcc version greater than 4.3.
> >>
> >> So still need to check gcc version. Any other solution?
> >>
> >> Thanks,
> >> Michael
> >>
> >>> ? 2015?11?278:34?Ananyev, Konstantin  >>> intel.com> ???
> >>>
> >>>
>  -Original Message-
>  From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qiu, Michael
>  Sent: Friday, November 27, 2015 11:53 AM
>  To: Thomas Monjalon
>  Cc: dev at dpdk.org
>  Subject: Re: [dpdk-dev] [PATCH] lib/librte_sched: Fix compile with gcc 
>  4.3.4
> 
>  really?I don't think so.
> 
>  AVX Marco only exist in the gcc version below 4.4,  I still need to 
>  check if below or beyond 4.4 am I right?
> 
>  Thanks,
>  Michael
> >>>
> >>>
> >>> If you look at lib/librte_eal/common/include/arch/x86/rte_vect.h, you'll 
> >>> see the code similar
> >>> to one you are trying to put into rte_shed.c:
> >>>
> >>> lib/librte_eal/common/include/arch/x86/rte_vect.h:
> >>> ...
> >>> #if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
> >>>
> >>> #ifdef __SSE__
> >>> #include 
> >>> #endif
> >>>
> >>> #ifdef __SSE2__
> >>> #include 
> >>> #endif
> >>>
> >>> #ifdef __SSE3__
> >>> #include 
> >>> #endif
> >>>
> >>> #if defined(__SSE4_2__) || defined(__SSE4_1__)
> >>> #include 
> >>> #endif
> >>>
> >>> #if defined(__AVX__)
> >>> #include 
> >>> #endif
> >>>
> >>> #else
> >>>
> >>> #include 
> >>>
> >>> #endif
> >>> ...
> >>>
> >>> So I think you can do just like that:
> >>>
> >>> #include 
> >>> #if defined(__AVX__)
> >>> #define SCHED_VECTOR_ENABLE
> >>> #endif
> >>>
> >>> inside rte_sched.c
> >>>
> >>> Konstantin
> >>>
> >>>
> 
> 
> > ? 2015?11?275:01?Thomas Monjalon  ???
> >
> > 2015-11-27 02:26, Qiu, Michael:
>  On 2015/11/27 5:29, Thomas Monjalon wrote:
>  2015-11-26 18:49, Michael Qiu:
>  gcc 4.3.4 does not include "immintrin.h", and will post below error:
>   lib/librte_sched/rte_sched.c:56:23: error:
>   immintrin.h: No such file or directory
> 
>  To avoid this issue, a gcc version check is need and a flag to 
>  indicate
>  vector ablility.
> >>> [...]
>  +#if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
>  +
>  +#if defined(__AVX__)
>  #include 
>  +#define SCHED_VECTOR_ENABLE
>  +#endif
>  +
>  +#else
>  +
>  +#include 
>  +#define SCHED_VECTOR_ENABLE
>  +
>  +#endif
> >>> This kind of complication is managed by EAL.
> >>> I think we should include rte_vect.h.
> >>
> >> As I know here it needs a flag to identify whether the platform support
> >> AVX, if not it will not use it, so I don't know if we could only simply
> >> include rte_vect.h?
> >
> > It's not exclusive.
> > You can include rte_vect.h and check AVX to define SCHED_VECTOR_ENABLE.
> >

[dpdk-dev] [PATCH] config: disable CONFIG_RTE_SCHED_VECTOR for arm

[Jerin Jacob]

On Fri, Nov 27, 2015 at 11:23:01AM +0100, Thomas Monjalon wrote:
> Hi Jerin,
> 
> 2015-11-27 15:23, Jerin Jacob:
> > Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
> > does support only SSE intrinsic, so disable it till we have neon support.
> > 
> > Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")
> > 
> > Signed-off-by: Jerin Jacob 
> > ---
> >  config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
> >  config/defconfig_arm64-armv8a-linuxapp-gcc   | 1 +
> >  config/defconfig_arm64-thunderx-linuxapp-gcc | 1 +
> >  config/defconfig_arm64-xgene1-linuxapp-gcc   | 1 +
> 
> You would not need to update 4 files if the 3 last ones were including the
> first one.

armv7 and armv8 config parameters are quite different.I think we
can converge all the common configs of defconfig_arm64-*

> I think having an arm config base would also make clearer the differences
> between the arm platforms.

Yes, For armv8, I can update arm64-armv8a-linuxapp-gcc as a base config
and only absolute delta changes can be added to thunderx/xgene1 config.

I will send out the next revision with arm64-armv8a-linuxapp-gcc as
a base config.

Thanks
Jerin

[dpdk-dev] [PATCH v3 2/2] doc: correct Rings-based PMD section in the NIC Drivers guides

[Bruce Richardson]

On Fri, Nov 27, 2015 at 04:07:40PM +, Bernard Iremonger wrote:
> Correct the sample code in the pcap_ring.rst file to match the latest
> rte_eth_ring.c code.
> 
> The parameters to the rte_eth_from_rings() function have changed since
> the documentation was written.
> The API change occurred before DPDK 1.8 when the rst files were added.
> The original documentation on which the pcap_ring.rst file was based was
> not correct.
> 
> Fixes: correct the sample code in the pcap_ring.rst file.

This is not a standard fixes line. Please add the following alias to your
.gitconfig and then use "git fixline " to produce a correct fixes
line identifying the commit being fixed.

[alias]
fixline = log -1 --abbrev=12 --format='Fixes: %h (\"%s\")'


/Bruce

[dpdk-dev] [PATCH v3 1/2] app/test: fix failures in the ring_pmd_autotest program

[Bruce Richardson]

On Fri, Nov 27, 2015 at 04:07:39PM +, Bernard Iremonger wrote:
> If eth_ring vdevs are created from the command line with the --vdev option,
> they create there own rings which are not shared by other vdevs.

Typo: s/their/there/

> Some of tests in this suite require that the vdevs share rings, so some
> of the tests fail.
> 
> For vdevs to share rings they must be created in the test code with the
> rte_eth_from_rings() function using rings created with the rte_ring_create()
> function.
> 
> Use the command line option --vdev=eth_ring0 to create port 0.

As I understand it, this option is not mandatory for the tests to pass, it only
allows some additional functional tests on cmd-line created rings to be run.
This should perhaps still be called out in the commit message.

> Create two rings and five ethdevs in test_pmd_ring.c for ports 1 to 5.
"... and then use these to run the unit tests on the pmd ring functionality"


> Improve test output by adding the port number to printf statements,
> and adding a printf describing each test.
>

/Bruce

[dpdk-dev] [PATCH v3 6/8] mk: Add rule for installing nic bind files

[Bruce Richardson]

On Fri, Nov 27, 2015 at 04:52:11PM +0100, Thomas Monjalon wrote:
> 2015-10-02 10:54, Richardson, Bruce:
> > I think there are better utilities available for determining the core layout
> > that cpu_layout.py. "lstopo", for one, is much more powerful. Do we 
> > want/need
> > to keep our own script around for that?
> 
> Good question.
> Anyone against dropping cpu_layout.py?

At this late stage in the release, yes. In 2.3 or future release, none on my 
part.
:-)

/Bruce

[dpdk-dev] [PATCH v3 2/2] doc: correct Rings-based PMD section in the NIC Drivers guides

[Bernard Iremonger]

Correct the sample code in the pcap_ring.rst file to match the latest
rte_eth_ring.c code.

The parameters to the rte_eth_from_rings() function have changed since
the documentation was written.
The API change occurred before DPDK 1.8 when the rst files were added.
The original documentation on which the pcap_ring.rst file was based was
not correct.

Fixes: correct the sample code in the pcap_ring.rst file.

Signed-off-by: Bernard Iremonger 
Acked-by: Bruce Richardson 
---
 doc/guides/nics/pcap_ring.rst | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/doc/guides/nics/pcap_ring.rst b/doc/guides/nics/pcap_ring.rst
index 5d65dc6..46aa3ac 100644
--- a/doc/guides/nics/pcap_ring.rst
+++ b/doc/guides/nics/pcap_ring.rst
@@ -1,5 +1,5 @@
 ..  BSD LICENSE
-Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
 All rights reserved.

 Redistribution and use in source and binary forms, with or without
@@ -217,7 +217,7 @@ Using the Poll Mode Driver from an Application
 Both drivers can provide similar APIs to allow the user to create a PMD, that 
is,
 rte_ethdev structure, instances at run-time in the end-application,
 for example, using rte_eth_from_rings() or rte_eth_from_pcaps() APIs.
-For the rings- based PMD, this functionality could be used, for example,
+For the rings-based PMD, this functionality could be used, for example,
 to allow data exchange between cores using rings to be done in exactly the
 same way as sending or receiving packets from an Ethernet device.
 For the libpcap-based PMD, it allows an application to open one or more pcap 
files
@@ -231,26 +231,30 @@ for reception on the same port (error handling omitted 
for clarity):

 .. code-block:: c

-struct rte_ring *r1, *r2;
-int port1, port2;
+#define RING_SIZE 256
+#define NUM_RINGS 2
+#define SOCKET0 0

-r1 = rte_ring_create("R1", 256, SOCKET0,RING_F_SP_ENQ|RING_F_SC_DEQ);
-r2 = rte_ring_create("R2", 256, SOCKET0, RING_F_SP_ENQ|RING_F_SC_DEQ);
+struct rte_ring *ring[NUM_RINGS];
+int port0, port1;

-/* create an ethdev where RX and TX are done to/from r1, and * another 
from r2 */
+ring[0] = rte_ring_create("R0", RING_SIZE, SOCKET0, 
RING_F_SP_ENQ|RING_F_SC_DEQ);
+ring[1] = rte_ring_create("R1", RING_SIZE, SOCKET0, 
RING_F_SP_ENQ|RING_F_SC_DEQ);

-port1 = rte_eth_from_rings(r1, 1, r1, 1, SOCKET0);
-port2 = rte_eth_from_rings(r2, 1, r2, 1, SOCKET0);
+/* create two ethdev's */
+
+port0 = rte_eth_from_rings("eth_ring0", ring, NUM_RINGS, ring, NUM_RINGS, 
SOCKET0);
+port1 = rte_eth_from_rings("eth_ring1", ring, NUM_RINGS, ring, NUM_RINGS, 
SOCKET0);


 To create two pseudo-Ethernet ports where the traffic is switched between them,
-that is, traffic sent to port 1 is read back from port 2 and vice-versa,
+that is, traffic sent to port 0 is read back from port 1 and vice-versa,
 the final two lines could be changed as below:

 .. code-block:: c

-port1 = rte_eth_from_rings(r1, 1, r2, 1, SOCKET0);
-port2 = rte_eth_from_rings(r2, 1, r1, 1, SOCKET0);
+port0 = rte_eth_from_rings("eth_ring0", [0], 1, [1], 1, SOCKET0);
+port1 = rte_eth_from_rings("eth_ring1", [1], 1, [0], 1, SOCKET0);

 This type of configuration could be useful in a pipeline model, for example,
 where one may want to have inter-core communication using pseudo Ethernet 
devices rather than raw rings,
-- 
1.9.1

[dpdk-dev] [PATCH v3 1/2] app/test: fix failures in the ring_pmd_autotest program

[Bernard Iremonger]

If eth_ring vdevs are created from the command line with the --vdev option,
they create there own rings which are not shared by other vdevs.
Some of tests in this suite require that the vdevs share rings, so some
of the tests fail.

For vdevs to share rings they must be created in the test code with the
rte_eth_from_rings() function using rings created with the rte_ring_create()
function.

Use the command line option --vdev=eth_ring0 to create port 0.
Create two rings and five ethdevs in test_pmd_ring.c for ports 1 to 5.
Improve test output by adding the port number to printf statements,
and adding a printf describing each test.

Signed-off-by: Bernard Iremonger 
Acked-by: Bruce Richardson 
---
 app/test/test_pmd_ring.c | 360 ---
 1 file changed, 219 insertions(+), 141 deletions(-)

diff --git a/app/test/test_pmd_ring.c b/app/test/test_pmd_ring.c
index a555db8..5568759 100644
--- a/app/test/test_pmd_ring.c
+++ b/app/test/test_pmd_ring.c
@@ -1,7 +1,7 @@
 /*-
  *   BSD LICENSE
  *
- *   Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ *   Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
  *   All rights reserved.
  *
  *   Redistribution and use in source and binary forms, with or without
@@ -38,108 +38,104 @@
 #include 

 static struct rte_mempool *mp;
+static int tx_porta, rx_portb, rxtx_portc, rxtx_portd, rxtx_porte;

-#define TX_PORT 0
-#define RX_PORT 1
-#define RXTX_PORT 2
-#define RXTX_PORT2 3
-#define RXTX_PORT3 4
 #define SOCKET0 0
-
 #define RING_SIZE 256
+#define NUM_RINGS 2
+#define NB_MBUF 512

-#define NB_MBUF   512

 static int
-test_ethdev_configure(void)
+test_ethdev_configure_port(int port)
 {
struct rte_eth_conf null_conf;
struct rte_eth_link link;

memset(_conf, 0, sizeof(struct rte_eth_conf));

-   if ((TX_PORT >= RTE_MAX_ETHPORTS) || (RX_PORT >= RTE_MAX_ETHPORTS)\
-   || (RXTX_PORT >= RTE_MAX_ETHPORTS)) {
-   printf(" TX/RX port exceed max eth ports\n");
-   return -1;
-   }
-   if (rte_eth_dev_configure(TX_PORT, 1, 2, _conf) < 0) {
-   printf("Configure failed for TX port\n");
+   if (rte_eth_dev_configure(port, 1, 2, _conf) < 0) {
+   printf("Configure failed for port %d\n", port);
return -1;
}

/* Test queue release */
-   if (rte_eth_dev_configure(TX_PORT, 1, 1, _conf) < 0) {
-   printf("Configure failed for TX port\n");
-   return -1;
-   }
-   if (rte_eth_dev_configure(RX_PORT, 1, 1, _conf) < 0) {
-   printf("Configure failed for RX port\n");
-   return -1;
-   }
-   if (rte_eth_dev_configure(RXTX_PORT, 1, 1, _conf) < 0) {
-   printf("Configure failed for RXTX port\n");
+   if (rte_eth_dev_configure(port, 1, 1, _conf) < 0) {
+   printf("Configure failed for port %d\n", port);
return -1;
}

-   if (rte_eth_tx_queue_setup(TX_PORT, 0, RING_SIZE, SOCKET0, NULL) < 0) {
-   printf("TX queue setup failed\n");
-   return -1;
-   }
-   if (rte_eth_rx_queue_setup(RX_PORT, 0, RING_SIZE, SOCKET0,
-   NULL, mp) < 0) {
-   printf("RX queue setup failed\n");
-   return -1;
-   }
-   if (rte_eth_tx_queue_setup(RXTX_PORT, 0, RING_SIZE, SOCKET0, NULL) < 0) 
{
-   printf("TX queue setup failed\n");
+   if (rte_eth_tx_queue_setup(port, 0, RING_SIZE, SOCKET0, NULL) < 0) {
+   printf("TX queue setup failed port %d\n", port);
return -1;
}
-   if (rte_eth_rx_queue_setup(RXTX_PORT, 0, RING_SIZE, SOCKET0,
+
+   if (rte_eth_rx_queue_setup(port, 0, RING_SIZE, SOCKET0,
NULL, mp) < 0) {
-   printf("RX queue setup failed\n");
+   printf("RX queue setup failed port %d\n", port);
return -1;
}

-   if (rte_eth_dev_start(TX_PORT) < 0) {
-   printf("Error starting TX port\n");
+   if (rte_eth_dev_start(port) < 0) {
+   printf("Error starting port %d\n", port);
return -1;
}
-   if (rte_eth_dev_start(RX_PORT) < 0) {
-   printf("Error starting RX port\n");
+
+   rte_eth_link_get(port, );
+
+   return 0;
+}
+
+static int
+test_send_basic_packets(void)
+{
+   struct rte_mbuf  bufs[RING_SIZE];
+   struct rte_mbuf *pbufs[RING_SIZE];
+   int i;
+
+   printf("Testing send and receive RING_SIZE/2 packets (tx_porta -> 
rx_portb)\n");
+
+   for (i = 0; i < RING_SIZE/2; i++)
+   pbufs[i] = [i];
+
+   if (rte_eth_tx_burst(tx_porta, 0, pbufs, RING_SIZE/2) < RING_SIZE/2) {
+   printf("Failed to transmit packet burst port %d\n", tx_porta);
return -1;
}
-   if (rte_eth_dev_start(RXTX_PORT) < 0) {
-   printf("Error starting RX 

[dpdk-dev] [PATCH v3 0/2] ring pmd autotest

[Bernard Iremonger]

Fix failures in the ring_pmd_autotest program.
Correct errors in the ring PMD documentation.

Changes in v3:
rebase to latest code.
revicse commit messages.

Changes in v2:
move doc changes to a seperate patch.

Bernard Iremonger (2):
  app/test: fix failures in the ring_pmd_autotest program
  doc: correct Rings-based PMD section in the NIC Drivers guides

 app/test/test_pmd_ring.c  | 360 +-
 doc/guides/nics/pcap_ring.rst |  28 ++--
 2 files changed, 235 insertions(+), 153 deletions(-)

-- 
1.9.1

[dpdk-dev] [PATCH 7/7] mk: Add hierarchy-file support (linux mod)

[Ferruh Yigit]

On Fri, Nov 27, 2015 at 04:40:51PM +0100, Thomas Monjalon wrote:
> 2015-09-22 09:56, Panu Matilainen:
> > On 09/18/2015 11:33 PM, Mario Carrillo wrote:
> > > +MOD_DIR := $(DESTDIR)/lib/modules
> > > +KERNEL_DIR := $(shell uname -r)/extra
> > 
> > Please don't assume one is always building for the running kernel. 
> > Defaulting around uname -r is perfectly reasonable, but there needs to 
> > be a way to override it from the cli. For example rte.vars.mk has this:
> > 
> > # can be overriden by make command line or exported environment variable
> > RTE_KERNELDIR ?= /lib/modules/$(shell uname -r)/build
> 
> For info, the ?= operator is a way to give a default value after having
> included other makefiles which may set a different value.
> Both ?= and := (or simply =) are overriden by the command line.
> Only "override VAR =" will not be overriden by the command line.
> 

As far as I know only "?=" assignment overridden by command line.

Basic experiment:

# cat Makefile 
A ?= a
B := b
C = c

all:
@echo $(A) $(B) $(C)

-

# make
a b c

# A=x B=x C=x make
x b c


ferruh

[dpdk-dev] [PATCH] example/ip_pipeline: fix resource leak problem.

[Fan Zhang]

This patch fix the following Coverity issue:

Coverity issue: 120147
Fixes: 7122d30131ad ("examples/ip_pipeline: rework flow classification
pipeline")

Signed-off-by: Fan Zhang 
---
 .../pipeline/pipeline_flow_classification_be.c | 31 +-
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/examples/ip_pipeline/pipeline/pipeline_flow_classification_be.c 
b/examples/ip_pipeline/pipeline/pipeline_flow_classification_be.c
index e22f96f..75a2a6b 100644
--- a/examples/ip_pipeline/pipeline/pipeline_flow_classification_be.c
+++ b/examples/ip_pipeline/pipeline/pipeline_flow_classification_be.c
@@ -141,12 +141,12 @@ pipeline_fc_parse_args(struct 
pipeline_flow_classification *p,
/* n_flows */
if (strcmp(arg_name, "n_flows") == 0) {
if (n_flows_present)
-   return -1;
+   goto error_parse;
n_flows_present = 1;

p->n_flows = atoi(arg_value);
if (p->n_flows == 0)
-   return -1;
+   goto error_parse;

continue;
}
@@ -154,7 +154,8 @@ pipeline_fc_parse_args(struct pipeline_flow_classification 
*p,
/* key_offset */
if (strcmp(arg_name, "key_offset") == 0) {
if (key_offset_present)
-   return -1;
+   goto error_parse;
+
key_offset_present = 1;

p->key_offset = atoi(arg_value);
@@ -165,14 +166,14 @@ pipeline_fc_parse_args(struct 
pipeline_flow_classification *p,
/* key_size */
if (strcmp(arg_name, "key_size") == 0) {
if (key_size_present)
-   return -1;
+   goto error_parse;
key_size_present = 1;

p->key_size = atoi(arg_value);
if ((p->key_size == 0) ||
(p->key_size > PIPELINE_FC_FLOW_KEY_MAX_SIZE) ||
(p->key_size % 8))
-   return -1;
+   goto error_parse;

continue;
}
@@ -180,11 +181,11 @@ pipeline_fc_parse_args(struct 
pipeline_flow_classification *p,
/* key_mask */
if (strcmp(arg_name, "key_mask") == 0) {
if (key_mask_present)
-   return -1;
+   goto error_parse;

key_mask_str = strdup(arg_value);
if (key_mask_str == NULL)
-   return -1;
+   goto error_parse;

key_mask_present = 1;

@@ -194,7 +195,7 @@ pipeline_fc_parse_args(struct pipeline_flow_classification 
*p,
/* hash_offset */
if (strcmp(arg_name, "hash_offset") == 0) {
if (hash_offset_present)
-   return -1;
+   goto error_parse;
hash_offset_present = 1;

p->hash_offset = atoi(arg_value);
@@ -210,23 +211,29 @@ pipeline_fc_parse_args(struct 
pipeline_flow_classification *p,
if ((n_flows_present == 0) ||
(key_offset_present == 0) ||
(key_size_present == 0))
-   return -1;
+   goto error_parse;

if (key_mask_present) {
p->key_mask = rte_malloc(NULL, p->key_size, 0);
if (p->key_mask == NULL)
-   return -1;
+   goto error_parse;

if (parse_hex_string(key_mask_str, p->key_mask, >key_size)
!= 0) {
-   free(p->key_mask);
-   return -1;
+   goto error_parse;
}

free(key_mask_str);
}

return 0;
+
+error_parse:
+   if (key_mask_str != NULL)
+   free(key_mask_str);
+   if (p->key_mask != NULL)
+   free(p->key_mask);
+   return -1;
 }

 static void *pipeline_fc_init(struct pipeline_params *params,
-- 
2.5.0

[dpdk-dev] [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm

[Thomas Monjalon]

2015-11-27 15:40, Jan Viktorin:
> Hello,
> 
> this what I was talking about at the Userspace Summit in Dublin...
> Somebody adds a feature or change a default setting and it breaks
> builds of other configurations and platforms. The current build system
> in DPDK is really imperfect.

The issue is due to enablement of a new feature for every platforms without
dependency check.
Actually the patch should disable CONFIG_RTE_SCHED_VECTOR for every non-x86
platforms.
Another fix is discussed in another thread to disable the feature inside the
code if the platform cannot support it (currently AVX is required).

[dpdk-dev] [PATCH v3 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm

[Jan Viktorin]

Hello,

this what I was talking about at the Userspace Summit in Dublin...
Somebody adds a feature or change a default setting and it breaks
builds of other configurations and platforms. The current build system
in DPDK is really imperfect.

Thanks for catching this!

Regards
Jan V.

On Fri, 27 Nov 2015 19:04:26 +0530
Jerin Jacob  wrote:

> v1..v2
> created common arm64 configs under common_arm64 file.
> let  each armv8 machine targets  capture only the differences
> between the common arm64 config.
> 
> v2..v3
> Fix whitespace issue with git am
> 
> Jerin Jacob (2):
>   config: arm64: create common arm64 configs under common_arm64 file
>   config: disable CONFIG_RTE_SCHED_VECTOR for arm
> 
>  config/common_arm64  | 49 
> 
>  config/defconfig_arm-armv7a-linuxapp-gcc |  1 +
>  config/defconfig_arm64-armv8a-linuxapp-gcc   | 18 +-
>  config/defconfig_arm64-thunderx-linuxapp-gcc | 18 +-
>  config/defconfig_arm64-xgene1-linuxapp-gcc   | 18 +-
>  5 files changed, 53 insertions(+), 51 deletions(-)
>  create mode 100644 config/common_arm64
> 



-- 
   Jan Viktorin  E-mail: Viktorin at RehiveTech.com
   System Architect  Web:www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

[dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm

[Jan Viktorin]

Acked-By: Jan Viktorin 

On Fri, 27 Nov 2015 19:04:28 +0530
Jerin Jacob  wrote:

> Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
> does support only SSE intrinsic, so disable it till we have neon support.
> 
> Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")
> 
> Signed-off-by: Jerin Jacob 
> ---
>  config/common_arm64  | 1 +
>  config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/config/common_arm64 b/config/common_arm64
> index 5e5e303..d6a9cb9 100644
> --- a/config/common_arm64
> +++ b/config/common_arm64
> @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
>  CONFIG_RTE_LIBRTE_LPM=n
>  CONFIG_RTE_LIBRTE_TABLE=n
>  CONFIG_RTE_LIBRTE_PIPELINE=n
> +CONFIG_RTE_SCHED_VECTOR=n
> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
> b/config/defconfig_arm-armv7a-linuxapp-gcc
> index 82143af..9924ff9 100644
> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n
>  CONFIG_RTE_LIBRTE_LPM=n
>  CONFIG_RTE_LIBRTE_TABLE=n
>  CONFIG_RTE_LIBRTE_PIPELINE=n
> +CONFIG_RTE_SCHED_VECTOR=n
>  
>  # cannot use those on ARM
>  CONFIG_RTE_KNI_KMOD=n

[dpdk-dev] [PATCH] maintainers: claim responsability for various sample apps

[Thomas Monjalon]

2015-11-27 14:14, Pablo de Lara:
> Co-maintain helloworld, l2fwd and dpdk-qat sample apps.

Naive question: what is the benefit of dpdk-qat compared to l2fwd-crypto?
Is it something we can drop?

[dpdk-dev] [PATCH] config: disable CONFIG_RTE_SCHED_VECTOR for arm

[Jerin Jacob]

Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
does support only SSE intrinsic, so disable it till we have neon support.

Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")

Signed-off-by: Jerin Jacob 
---
 config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
 config/defconfig_arm64-armv8a-linuxapp-gcc   | 1 +
 config/defconfig_arm64-thunderx-linuxapp-gcc | 1 +
 config/defconfig_arm64-xgene1-linuxapp-gcc   | 1 +
 4 files changed, 4 insertions(+)

diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
b/config/defconfig_arm-armv7a-linuxapp-gcc
index 82143af..9924ff9 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n
 CONFIG_RTE_LIBRTE_LPM=n
 CONFIG_RTE_LIBRTE_TABLE=n
 CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_SCHED_VECTOR=n

 # cannot use those on ARM
 CONFIG_RTE_KNI_KMOD=n
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc 
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 49e7056..504f3ed 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -54,3 +54,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
 CONFIG_RTE_LIBRTE_LPM=n
 CONFIG_RTE_LIBRTE_TABLE=n
 CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_SCHED_VECTOR=n
diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc 
b/config/defconfig_arm64-thunderx-linuxapp-gcc
index 6b2048b..8b10310 100644
--- a/config/defconfig_arm64-thunderx-linuxapp-gcc
+++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
@@ -54,3 +54,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
 CONFIG_RTE_LIBRTE_LPM=n
 CONFIG_RTE_LIBRTE_TABLE=n
 CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_SCHED_VECTOR=n
diff --git a/config/defconfig_arm64-xgene1-linuxapp-gcc 
b/config/defconfig_arm64-xgene1-linuxapp-gcc
index d75f8f0..7f72d01 100644
--- a/config/defconfig_arm64-xgene1-linuxapp-gcc
+++ b/config/defconfig_arm64-xgene1-linuxapp-gcc
@@ -54,3 +54,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
 CONFIG_RTE_LIBRTE_LPM=n
 CONFIG_RTE_LIBRTE_TABLE=n
 CONFIG_RTE_LIBRTE_PIPELINE=n
+CONFIG_RTE_SCHED_VECTOR=n
-- 
2.1.0

[dpdk-dev] [PATCH] cryptodev: mark experimental state

[Panu Matilainen]

On 11/26/2015 03:51 PM, Doherty, Declan wrote:
>> -Original Message-
>> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
>> Sent: Thursday, November 26, 2015 10:09 AM
>> To: Panu Matilainen; Doherty, Declan
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] cryptodev: mark experimental state
>>
>> 2015-11-26 10:00, Panu Matilainen:
>>> On 11/26/2015 09:39 AM, Panu Matilainen wrote:
 On 11/25/2015 07:38 PM, Thomas Monjalon wrote:
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -319,6 +319,7 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y
>
>#
># Compile generic crypto device library
> +# EXPERIMENTAL: API may change without prior notice
>#
>CONFIG_RTE_LIBRTE_CRYPTODEV=y
>CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n
 [...]

 I think an experimental library which declares itself exempt from the
 ABI policy should not be compiled by default. That way anybody wanting
 to try it out will be forced to notice the experimental status.

 More generally / longer term, perhaps there should be a
 CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and
 defaults to off.
>>>
>>> On a related note, librte_mbuf_offload cannot be built if
>>> CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at
>>> least currently) so tightly couple to cryptodev that perhaps it too
>>> should be marked experimental and default to off.
>>
>> I think you are right.
>> Declan, what is your opinion?
>
>
> Hey Thomas, yes librte_mbuf_offload should also be set as experimental, it's
> probably one of the areas which will most likely change in the future.
>
> On the issue of turning off experimental libraries in the build by default, my
> preference would be not to turn them off unless the library has external
> dependencies, otherwise the possibility of patches being submitted which
> could break an experimental library will be much higher. In my opinion the
> fewer build configurations developers have to test against the better.

What I'm more worried about is users and developers starting to rely on 
it while still in experimental state, a single comment in the header is 
really easy to miss.

So I'd like to see *some* mechanism which forces users and developers to 
acknowledge the fact that they're dealing with experimental work. 
Defaulting to off is one possibility, another one would be wrapping 
experimental APIs behind a define which you have to set to be able to 
use the API, eg:

#if defined(I_KNOW_THIS_IS_EXPERIMENTAL_AND_MAY_EAT_BABIES)
[...]
#endif

- Panu -

[dpdk-dev] [PATCH] maintainers: claim responsability for various sample apps

[Declan Doherty]

On 27/11/15 14:31, Thomas Monjalon wrote:
> 2015-11-27 14:14, Pablo de Lara:
>> Co-maintain helloworld, l2fwd and dpdk-qat sample apps.
>
> Naive question: what is the benefit of dpdk-qat compared to l2fwd-crypto?
> Is it something we can drop?
>

So the dpdk-qat sample application is a sample of how to use the QAT 
library APIs from a DPDK application allowing the user to schedule work 
with the QAT kernel devices. The QAT API has support for a number of QAT 
devices (both the cave-creek and coleto-creek family of devices) which 
support symmetric crypto, asymmetric crypto and compression operations.

The l2fwd application demonstrates using the new DPDK symmetric crypto 
APIs in packet processing work flow, with the crypto processing 
implemented by DPDK userspace PMDs, this currently includes support for 
both the AES-NI multi-buffer PMD as well as the QAT PMD.

Declan

[dpdk-dev] [PATCH v2] scripts: add git hook scripts for checkpatch and auto doc generation

[Ferruh Yigit]

These scripts are to automate some common tasks, scripts needs
to be deployed to specific folder to become active.

Scripts:
post-commit: Triggers after commit complete, re-generates api and
guides html documents. "RTE_DOC_OUT" environment variable configures
document output folder. Same script can be used on server side with
name "post-update", so documentation can auto updated after each push
to server.

post-merge: Same script as "post-commit", but triggered after git pull

pre-commit: Does a checkpatch check before commit started. This script
relies on scripts/checkpatches.sh script. checkpathes.sh should be
running well to use this git hook script.
This script can bypassed by commit "--no-verify" argument.

Deployment:
To make scripts active they need to be in /.git/hooks folder.
Alternatively "deploy.sh" script can be used, it simply links all
scripts into proper folder. Script names are significant and
shouldn't changed.

Signed-off-by: Ferruh Yigit 
---
 scripts/checkpatches.sh   |  1 +
 scripts/git-hooks/deploy.sh   | 20 
 scripts/git-hooks/post-commit | 10 ++
 scripts/git-hooks/post-merge  |  1 +
 scripts/git-hooks/pre-commit  | 17 +
 5 files changed, 49 insertions(+)
 create mode 100755 scripts/git-hooks/deploy.sh
 create mode 100755 scripts/git-hooks/post-commit
 create mode 12 scripts/git-hooks/post-merge
 create mode 100755 scripts/git-hooks/pre-commit

diff --git a/scripts/checkpatches.sh b/scripts/checkpatches.sh
index afc611b..8192514 100755
--- a/scripts/checkpatches.sh
+++ b/scripts/checkpatches.sh
@@ -43,6 +43,7 @@ length=${DPDK_CHECKPATCH_LINE_LENGTH:-80}

 # override default Linux options
 options="--no-tree"
+options="$options ${GIT_HOOK_OPTIONS}"
 options="$options --max-line-length=$length"
 options="$options --show-types"
 options="$options --ignore=LINUX_VERSION_CODE,FILE_PATH_CHANGES,\
diff --git a/scripts/git-hooks/deploy.sh b/scripts/git-hooks/deploy.sh
new file mode 100755
index 000..070fb6e
--- /dev/null
+++ b/scripts/git-hooks/deploy.sh
@@ -0,0 +1,20 @@
+
+SELF=$(basename $0)
+
+if [ ! -f ${SELF} ]; then
+   echo "Please run script from folder where script is"
+   exit 1
+fi
+
+FILES=$(ls | grep -v ${SELF})
+
+TARGET_FOLDER="../../.git/hooks"
+SCRIPT_FOLDER="../../scripts/git-hooks"
+
+if [ ! -d ${TARGET_FOLDER} ]; then
+   exit 2
+fi
+
+for f in ${FILES}; do
+   ln -sf ${SCRIPT_FOLDER}/${f} ${TARGET_FOLDER}/${f}
+done;
diff --git a/scripts/git-hooks/post-commit b/scripts/git-hooks/post-commit
new file mode 100755
index 000..2a76f96
--- /dev/null
+++ b/scripts/git-hooks/post-commit
@@ -0,0 +1,10 @@
+#
+# Create docs after each commit
+#
+
+if [ -n "$RTE_DOC_OUT" ]; then
+   OUT_CMD="O=${RTE_DOC_OUT}"
+fi
+
+make ${OUT_CMD} doc-guides-html 2>&1 > /dev/null
+make ${OUT_CMD} doc-api-html 2>&1 > /dev/null
diff --git a/scripts/git-hooks/post-merge b/scripts/git-hooks/post-merge
new file mode 12
index 000..ace4560
--- /dev/null
+++ b/scripts/git-hooks/post-merge
@@ -0,0 +1 @@
+post-commit
\ No newline at end of file
diff --git a/scripts/git-hooks/pre-commit b/scripts/git-hooks/pre-commit
new file mode 100755
index 000..c46b27d
--- /dev/null
+++ b/scripts/git-hooks/pre-commit
@@ -0,0 +1,17 @@
+#
+# Check patch with checkpatch script before commit
+#
+# If checkpatch fails, commit fails
+#
+# Relies on scripts/checkpathes.sh script as checkpatch.pl wrapper
+#
+# If "git commit" called with "--no-verify" option, pre-commit hooks
+# bypassed and this script not called, checkpatch bypassed
+#
+
+RTE_CHECKPATCH=$PWD/scripts/checkpatches.sh
+PATCH=/tmp/dpdk-git-auto-checkpatch-$$.patch
+export GIT_HOOK_OPTIONS=--no-signoff
+
+git diff --cached > ${PATCH}
+exec ${RTE_CHECKPATCH} ${PATCH}
-- 
2.5.0

[dpdk-dev] [PATCH] maintainers: claim responsability for various sample apps

[Bruce Richardson]

On Fri, Nov 27, 2015 at 02:14:04PM +, Pablo de Lara wrote:
> Co-maintain helloworld, l2fwd and dpdk-qat sample apps.
> 
> Signed-off-by: Pablo de Lara 
> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)
>
Thanks Pablo.
While these aren't a huge deal of work to maintain, it's good to have the help
so I can focus more time on drivers/net in future releases.

Acked-by: Bruce Richardson 

[dpdk-dev] [PATCH] cryptodev: mark experimental state

[Thomas Monjalon]

2015-11-27 15:09, Panu Matilainen:
> On 11/26/2015 03:51 PM, Doherty, Declan wrote:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> >> 2015-11-26 10:00, Panu Matilainen:
> >>> On 11/26/2015 09:39 AM, Panu Matilainen wrote:
>  I think an experimental library which declares itself exempt from the
>  ABI policy should not be compiled by default. That way anybody wanting
>  to try it out will be forced to notice the experimental status.
> 
>  More generally / longer term, perhaps there should be a
>  CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and
>  defaults to off.
> >>>
> >>> On a related note, librte_mbuf_offload cannot be built if
> >>> CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at
> >>> least currently) so tightly couple to cryptodev that perhaps it too
> >>> should be marked experimental and default to off.
> >>
> >> I think you are right.
> >> Declan, what is your opinion?
> >
> >
> > Hey Thomas, yes librte_mbuf_offload should also be set as experimental, it's
> > probably one of the areas which will most likely change in the future.
> >
> > On the issue of turning off experimental libraries in the build by default, 
> > my
> > preference would be not to turn them off unless the library has external
> > dependencies, otherwise the possibility of patches being submitted which
> > could break an experimental library will be much higher. In my opinion the
> > fewer build configurations developers have to test against the better.
> 
> What I'm more worried about is users and developers starting to rely on 
> it while still in experimental state, a single comment in the header is 
> really easy to miss.

There are some comments in the config, the header file, doxygen and the release 
notes.
When using a feature, you have to read the header or the doc.
So would it be better advertised by adding a comment in the doxygen section of
some of the mandatory functions or structures?

> So I'd like to see *some* mechanism which forces users and developers to 
> acknowledge the fact that they're dealing with experimental work. 
> Defaulting to off is one possibility, another one would be wrapping 
> experimental APIs behind a define which you have to set to be able to 
> use the API, eg:
> 
> #if defined(I_KNOW_THIS_IS_EXPERIMENTAL_AND_MAY_EAT_BABIES)
> [...]
> #endif

Are you sure about the babies? ;)

[dpdk-dev] FW: OVS with DPDK Meetup notes

[Mcnamara, John]

Cross posting this from users at dpdk.org to get great visibility.


> -Original Message-
> From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Traynor, Kevin
> Sent: Thursday, November 26, 2015 5:56 PM
> To: dev at openvswitch.org
> Cc: users at dpdk.org
> Subject: [ovs-dev] OVS with DPDK Meetup notes



Hi All,

Just wanted to post some summary notes on the recent OVS with DPDK Meetup we 
had after the OVS conference. Thanks to everyone for the often lively 
discussion. 
I've collated and condensed Maryam's notes (Thank you Maryam) with my own. 
Corrections and additions are welcome.

Usability
==
* Command line options
  - Create defaults which can be overridden on the command line.
  -c 0x1
  -n 4 (this will be in DPDK 2.2 also)
  -socket-mem 1024,0 

* igb / vfio / uio
  - Update documentation to explain these better.

* 1GB v 2MB Hugepages
  - Test to see if significant performance difference between them and if not,
update documentation to preference 2 MB pages. 

* Assignment of queues to cores/PMD threads
  - Would like to allow for better load balancing of traffic across cores.
  - Add appctl command to get the current queue/core assignments (currently 
it's only in logs).
  - Discussion about relative merits of trying to do something better than 
current scheme automatically or allowing a user interface to configure 
manually. General consensus seemed to be that while it might be difficult 
to do well automatically, it would be good to investigate and exhaust that 
possibility before adding a manual user config.
  - Possibility of using DPDK light weight threads discussed.

* Debugging
  - A tcpdump type solution would be nice. Follow DPDK and leverage.

* More flexible port names / auto-discovery of ports
  - Follow DPDK and leverage.

* Single binary for OVS/OVS with DPDK and static vs. dynamic linking
  - Discussion around deployment and what the best model is.
  - Flavio has posted a mail on this
   http://openvswitch.org/pipermail/dev/2015-November/062599.html

* Documentation
  - Make INSTALL.DPDK.md guide cover the most common use cases only, and split 
the other stuff into a less common/advanced guide. 

Testing
===
* General agreement in the room that VSPERF pushing a nightly test report for
  OVS/OVS with DPDK to the ovs-build ML would be useful.

* Static Analysis
  - Is there an open source static analysis tool that the community could all 
use?

Features

* Multiqueue vhost-user
  - Looks really promising - will help us scale out performance to the VM. 

* vhost-cuse
  - Still used by some. Give notice to deprecate as there's a maintenance cost. 
2 releases was mentioned, but I'm not sure that's clear to a user without a 
regular release cadence. 

* dpdkr/ivshmem
  - Still useful. Check/Update documentation to ensure limitations are clear.


Performance
===
* Some new optimizations coming in DPDK for vhost performance that we can
  leverage.
* Scalability
  - Performance is scaling well across cores (See Gerald Roger's OVS conf 
presentation for reference)


At that point everyone was "conferenced out", but tentative plan to arrange 
another meetup in ~6 months' time if there's enough discussion items to warrant 
it.

Thanks,
Kevin.

[dpdk-dev] dpdk proposal installation process

[Marc]

On 22 October 2015 at 16:57, Bruce Richardson 
wrote:

> On Thu, Oct 22, 2015 at 08:55:41AM +0300, Panu Matilainen wrote:
> > On 10/21/2015 10:15 PM, Olivier MATZ wrote:
> > >Hi Mario,
> > >
> > >On 10/20/2015 11:17 AM, Bruce Richardson wrote:
> > >>On Tue, Oct 20, 2015 at 12:21:00AM +, Arevalo, Mario Alfredo C
> wrote:
> > >>>Hi folks,
> > >>>
> > >>>   Good day, this is a proposal in order to improve the dpdk
> install process,
> > >>>I would like to know your point of view about the next points
> according to
> > >>>previous conversations :) in order to create a new patches version.
> > >>>
> > >>>1) I think the first thing that I have to be aware is
> "compatibility", the
> > >>>new changes won't affect the current dpdk behaviour.
> > >
> > >Yes. As I stated in a previous mail, I think nobody uses the current
> > >"make install" without specifying T= as the default value is to build
> > >and install for all targets.
> > >
> > >My suggestion is:
> > >
> > >- rename the previous "install" target. The name could probably
> > >   be "mbuild" (for multiple builds). Other ideas are welcome.
> > >
> > >- when "make install" is invoked with T= argument, call the mbuild
> > >   target to have the same behavior than before. This compat layer
> > >   could be removed in the future.
> > >
> > >- when "make install" is invoked without T=, it installs the fhs.
> >
> > Nice, this sounds like the best of both worlds.
> >
> > >
> > >>>2) Create new makefile rules, these rules is going to install dpdk
> files in
> > >>>default paths, however the linux distributions don't use the same
> paths for their
> > >>>files, the linux distribution and the architecture can be factor for
> different
> > >>>path as Panu commented in previous conversations, he is right, then
> all variables
> > >>>could be overridden, the variables names for the user can be included
> in documentation.
> > >>>Also an option could be a configuration file for paths, however I'm
> not sure.
> > >
> > >I think having variables is ok.
> > >
> > >>>3) The default paths for dpdk in order to follow a hierarchy, however
> the variable
> > >>>with those values can be overridden.
> > >>>
> > >>>-install-bin  --> /usr/bin.
> > >>>-install-headers  --> /usr/include/dpdk
> > >>>-install-lib   --> /usr/lib64
> > >
> > >I remember Panu suggested to have /usr/lib by default.
> > >I also think /usr/lib a better default value: some distributions
> > >use /usr/lib for 64 bits libs, but we never have 32 bits libs in
> > >/usr/lib64.
> >
> > Yes, just stick /usr/lib there and be done with it, lib64 is not a good
> > default for these very reasons.
> >
> > >>>-install-doc --> /usr/share/doc/dpdk
> > >>>-install-mod--> if RTE_EXEC_ENV=linuxapp then
> KERNEL_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk
> > >>> else KERNEL_DIR=/boot/modules).
> > >
> > >I'm not sure KERNEL_DIR is the proper name. Maybe KMOD_DIR?
> > >
> > >>>-install-sdk --> /usr/share/dpdk and call install-headers ).
> > >>>-install-fhs  --> call install-libraries, install-mod,
> install-bin and install-doc (maybe install-headers)
> > >>>
> > >>>4) I'm going to take account all feedback about variables, paths etc
> for the new version :).
> > >>>
> > >>>Thank you so much for your help.
> > >>>
> > >>>
> > >>>Mario.
> > >>
> > >>Hi Mario,
> > >>
> > >>that seems like a lot of commands to add - are they all individually
> needed?
> > >>
> > >>In terms of where things go, should the "usr" part not a) be
> configurable via
> > >>a parameter, and b) default to "/usr/local" as that's where
> user-installed
> > >>software from outside the packaging system normally gets put.
> > >
> > >A PREFIX variable would do the job.
> > >About the default to /usr or /usr/local, I agree that /usr/local looks
> > >more usual, and I don't think it's a problem for packaging as soon as
> > >it can be overridden.
> >
> > Yeah, PREFIX support would be nice, and defaulting that to /usr/local
> would
> > be the right thing.
> >
> >   - Panu -
> >
> > >
> > >
> > >Regards,
> > >Olivier
> > >
> >
>
> Can I throw a completely different suggestion into the mix?
>
> Can we make use of the fact that make config creates a directory called
> "build"
> by default. Then running "make" alone in that directory does the expected
> behaviour of a compile of the whole sdk. How about having "make install"
> in the
> build directory behave like a generic "make install" call for other
> packages?
>
> I'm imagining the following sequence of steps to install:
>
> ./configure --machine=[default|native|other]
> # configure is a simple script that just calls "make
> config T=..."
> cd build
>

Why not the inverse, configure in the folder where you build so that you
have all the compilation environment in the target folder  (as in
autoconf+automake and as of now in DPDK). You can have easily parallel
builds in different folders.



>  

[dpdk-dev] [PATCH] maintainers: claim responsability for various sample apps

[Pablo de Lara]

Co-maintain helloworld, l2fwd and dpdk-qat sample apps.

Signed-off-by: Pablo de Lara 
---
 MAINTAINERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4478862..6e0bb53 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -509,6 +509,7 @@ Other Example Applications
 --

 M: Bruce Richardson 
+M: Pablo de Lara 
 F: examples/dpdk_qat/
 F: doc/guides/sample_app_ug/intel_quickassist.rst

@@ -516,6 +517,7 @@ F: examples/exception_path/
 F: doc/guides/sample_app_ug/exception_path.rst

 M: Bruce Richardson 
+M: Pablo de Lara 
 F: examples/helloworld/
 F: doc/guides/sample_app_ug/hello_world.rst

@@ -523,6 +525,7 @@ F: examples/ipv4_multicast/
 F: doc/guides/sample_app_ug/ipv4_multicast.rst

 M: Bruce Richardson 
+M: Pablo de Lara 
 F: examples/l2fwd/
 F: doc/guides/sample_app_ug/l2_forward_real_virtual.rst

-- 
2.5.0

[dpdk-dev] [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4

[Ananyev, Konstantin]

> -Original Message-
> From: Qiu, Michael
> Sent: Friday, November 27, 2015 2:02 PM
> To: Ananyev, Konstantin
> Cc: Thomas Monjalon; dev at dpdk.org
> Subject: Re: [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4
> 
> I just replied that Marco AVX only exist in gcc version < 4.4 , otherwise it 
> will not exist.

If macro __AVX__ not defined, then 
#if defined(__AVX__)
would always be false and SCHED_VECTOR_ENABLE also wouldn't be defined.
So still don't understand why that is a problem
Konstantin

> 
> What's your suggest will not work if gcc version greater than 4.3.
> 
> So still need to check gcc version. Any other solution?
> 
> Thanks,
> Michael
> 
> > ? 2015?11?278:34?Ananyev, Konstantin  
> > ???
> >
> >
> >> -Original Message-
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qiu, Michael
> >> Sent: Friday, November 27, 2015 11:53 AM
> >> To: Thomas Monjalon
> >> Cc: dev at dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH] lib/librte_sched: Fix compile with gcc 
> >> 4.3.4
> >>
> >> really?I don't think so.
> >>
> >> AVX Marco only exist in the gcc version below 4.4,  I still need to check 
> >> if below or beyond 4.4 am I right?
> >>
> >> Thanks,
> >> Michael
> >
> >
> > If you look at lib/librte_eal/common/include/arch/x86/rte_vect.h, you'll 
> > see the code similar
> > to one you are trying to put into rte_shed.c:
> >
> > lib/librte_eal/common/include/arch/x86/rte_vect.h:
> > ...
> > #if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
> >
> > #ifdef __SSE__
> > #include 
> > #endif
> >
> > #ifdef __SSE2__
> > #include 
> > #endif
> >
> > #ifdef __SSE3__
> > #include 
> > #endif
> >
> > #if defined(__SSE4_2__) || defined(__SSE4_1__)
> > #include 
> > #endif
> >
> > #if defined(__AVX__)
> > #include 
> > #endif
> >
> > #else
> >
> > #include 
> >
> > #endif
> > ...
> >
> > So I think you can do just like that:
> >
> > #include 
> > #if defined(__AVX__)
> > #define SCHED_VECTOR_ENABLE
> > #endif
> >
> > inside rte_sched.c
> >
> > Konstantin
> >
> >
> >>
> >>
> >>> ? 2015?11?275:01?Thomas Monjalon  ???
> >>>
> >>> 2015-11-27 02:26, Qiu, Michael:
> >> On 2015/11/27 5:29, Thomas Monjalon wrote:
> >> 2015-11-26 18:49, Michael Qiu:
> >> gcc 4.3.4 does not include "immintrin.h", and will post below error:
> >>   lib/librte_sched/rte_sched.c:56:23: error:
> >>   immintrin.h: No such file or directory
> >>
> >> To avoid this issue, a gcc version check is need and a flag to indicate
> >> vector ablility.
> > [...]
> >> +#if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
> >> +
> >> +#if defined(__AVX__)
> >> #include 
> >> +#define SCHED_VECTOR_ENABLE
> >> +#endif
> >> +
> >> +#else
> >> +
> >> +#include 
> >> +#define SCHED_VECTOR_ENABLE
> >> +
> >> +#endif
> > This kind of complication is managed by EAL.
> > I think we should include rte_vect.h.
> 
>  As I know here it needs a flag to identify whether the platform support
>  AVX, if not it will not use it, so I don't know if we could only simply
>  include rte_vect.h?
> >>>
> >>> It's not exclusive.
> >>> You can include rte_vect.h and check AVX to define SCHED_VECTOR_ENABLE.
> >>>

[dpdk-dev] [PATCH] e1000: fix VF mac address issue

[Wenzhuo Lu]

If use DPDK PF + DPDK VF on igb NICs, we find the MAC address of VF
port is always 0. Because we forget to give it a value if this MAC
address is not assigned by PF. This patch'll assign a random MAC
address to igb VF port as ixgbe does.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/e1000/igb_ethdev.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 31452ae..6c2aa8c 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -846,6 +846,7 @@ eth_igbvf_dev_init(struct rte_eth_dev *eth_dev)
struct e1000_hw *hw =
E1000_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
int diag;
+   struct ether_addr *perm_addr = (struct ether_addr *)hw->mac.perm_addr;

PMD_INIT_FUNC_TRACE();

@@ -898,6 +899,26 @@ eth_igbvf_dev_init(struct rte_eth_dev *eth_dev)
return -ENOMEM;
}

+   /* Generate a random MAC address, if none was assigned by PF. */
+   if (is_zero_ether_addr(perm_addr)) {
+   eth_random_addr(perm_addr->addr_bytes);
+   diag = e1000_rar_set(hw, perm_addr->addr_bytes, 0);
+   if (diag) {
+   rte_free(eth_dev->data->mac_addrs);
+   eth_dev->data->mac_addrs = NULL;
+   return diag;
+   }
+   PMD_INIT_LOG(INFO, "\tVF MAC address not assigned by Host PF");
+   PMD_INIT_LOG(INFO, "\tAssign randomly generated MAC address "
+"%02x:%02x:%02x:%02x:%02x:%02x",
+perm_addr->addr_bytes[0],
+perm_addr->addr_bytes[1],
+perm_addr->addr_bytes[2],
+perm_addr->addr_bytes[3],
+perm_addr->addr_bytes[4],
+perm_addr->addr_bytes[5]);
+   }
+
/* Copy the permanent MAC address */
ether_addr_copy((struct ether_addr *) hw->mac.perm_addr,
_dev->data->mac_addrs[0]);
-- 
1.9.3

[dpdk-dev] [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4

[Qiu, Michael]

I just replied that Marco AVX only exist in gcc version < 4.4 , otherwise it 
will not exist.

What's your suggest will not work if gcc version greater than 4.3.

So still need to check gcc version. Any other solution?

Thanks,
Michael

> ? 2015?11?278:34?Ananyev, Konstantin  ???
> 
> 
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qiu, Michael
>> Sent: Friday, November 27, 2015 11:53 AM
>> To: Thomas Monjalon
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4
>> 
>> really?I don't think so.
>> 
>> AVX Marco only exist in the gcc version below 4.4,  I still need to check if 
>> below or beyond 4.4 am I right?
>> 
>> Thanks,
>> Michael
> 
> 
> If you look at lib/librte_eal/common/include/arch/x86/rte_vect.h, you'll see 
> the code similar
> to one you are trying to put into rte_shed.c:
> 
> lib/librte_eal/common/include/arch/x86/rte_vect.h:
> ...
> #if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
> 
> #ifdef __SSE__
> #include 
> #endif
> 
> #ifdef __SSE2__
> #include 
> #endif
> 
> #ifdef __SSE3__
> #include 
> #endif
> 
> #if defined(__SSE4_2__) || defined(__SSE4_1__)
> #include 
> #endif
> 
> #if defined(__AVX__)
> #include 
> #endif
> 
> #else
> 
> #include 
> 
> #endif
> ...
> 
> So I think you can do just like that:
> 
> #include 
> #if defined(__AVX__)
> #define SCHED_VECTOR_ENABLE
> #endif
> 
> inside rte_sched.c
> 
> Konstantin
> 
> 
>> 
>> 
>>> ? 2015?11?275:01?Thomas Monjalon  ???
>>> 
>>> 2015-11-27 02:26, Qiu, Michael:
>> On 2015/11/27 5:29, Thomas Monjalon wrote:
>> 2015-11-26 18:49, Michael Qiu:
>> gcc 4.3.4 does not include "immintrin.h", and will post below error:
>>   lib/librte_sched/rte_sched.c:56:23: error:
>>   immintrin.h: No such file or directory
>> 
>> To avoid this issue, a gcc version check is need and a flag to indicate
>> vector ablility.
> [...]
>> +#if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
>> +
>> +#if defined(__AVX__)
>> #include 
>> +#define SCHED_VECTOR_ENABLE
>> +#endif
>> +
>> +#else
>> +
>> +#include 
>> +#define SCHED_VECTOR_ENABLE
>> +
>> +#endif
> This kind of complication is managed by EAL.
> I think we should include rte_vect.h.
 
 As I know here it needs a flag to identify whether the platform support
 AVX, if not it will not use it, so I don't know if we could only simply
 include rte_vect.h?
>>> 
>>> It's not exclusive.
>>> You can include rte_vect.h and check AVX to define SCHED_VECTOR_ENABLE.
>>> 

[dpdk-dev] [PATCH 2/2] virtio: remove unnecessary rx_mbuf_alloc_failed counter clearing

[Igor Ryzhov]

This counter is cleared in rte_eth_stats_reset.

Signed-off-by: Igor Ryzhov 
---
 drivers/net/virtio/virtio_ethdev.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/virtio/virtio_ethdev.c 
b/drivers/net/virtio/virtio_ethdev.c
index 74c00ee..f5b72a3 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -788,8 +788,6 @@ virtio_dev_stats_reset(struct rte_eth_dev *dev)
rxvq->broadcast = 0;
memset(rxvq->size_bins, 0, sizeof(rxvq->size_bins[0]) * 8);
}
-
-   dev->data->rx_mbuf_alloc_failed = 0;
 }

 static void
-- 
2.4.9 (Apple Git-60)

[dpdk-dev] [PATCH 1/2] ethdev: clear rx_mbuf_alloc_failed counter on rte_eth_stats_reset

[Igor Ryzhov]

---
 lib/librte_ether/rte_ethdev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 3840775..41f5f0b 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1456,6 +1456,7 @@ rte_eth_stats_reset(uint8_t port_id)

RTE_FUNC_PTR_OR_RET(*dev->dev_ops->stats_reset);
(*dev->dev_ops->stats_reset)(dev);
+   dev->data->rx_mbuf_alloc_failed = 0;
 }

 /* retrieve ethdev extended statistics */
-- 
2.4.9 (Apple Git-60)

[dpdk-dev] [PATCH 0/2] Clear rx_mbuf_alloc_failed counter on rte_eth_stats_reset

[Igor Ryzhov]

The rx_mbuf_alloc_failed counter was only cleared by virtio driver.
Now it is cleared by common rte_eth_stats_clear function for all drivers at 
once.

Igor Ryzhov (2):
  ethdev: clear rx_mbuf_alloc_failed counter on rte_eth_stats_reset
  virtio: remove unnecessary rx_mbuf_alloc_failed counter clearing

 drivers/net/virtio/virtio_ethdev.c | 2 --
 lib/librte_ether/rte_ethdev.c  | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

-- 
2.4.9 (Apple Git-60)

[dpdk-dev] dpdk proposal installation process

[Thomas Monjalon]

2015-10-26 16:18, Arevalo, Mario Alfredo C:
> Hi Guys,
> 
> Thank you so much for your feedback, about your last comments,
> I understood the next:
> 
> 1)
> -"make install" using "T" variable:
> This command will use a rule for the current behaviour called "mbuild"

I think the ability of building several targets in one command make
the build system more complex than it should be.
A target should be defined by its configured options, not a default
template config.
So I suggest to drop it.

> -"make install" without "T" variable:
> This command will install everything: headers, libraries, modules, apps, 
> docs, and
> sdk files (config files, make files, scripts and examples).
> 
> 2) About variables, you rigth, KMOD_DIR sounds better than KERNEL_DIR,
> and LIB_DIR should be /usr/lib by default.
> 
> 3)
> -To use a "prefix variable"
> -This prefix variable will be "/usr/local" by default.
> -This prefix variable can be overridden.
> 
> Example:
> $(DESTDIR)/$(PREFIX)/$(INCLUDE_DIR)

It is a good step.
In order to be more standard, we should try to comply with these guidelines:
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
https://www.gnu.org/prep/standards/html_node/DESTDIR.html

> 4) What do you think about the Bruce's proposal?

I love the idea of having a configure script.
I would add some checks to solve the dependencies (external and internal).

[dpdk-dev] [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Qiu, Michael
> Sent: Friday, November 27, 2015 11:53 AM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4
> 
> really?I don't think so.
> 
> AVX Marco only exist in the gcc version below 4.4,  I still need to check if 
> below or beyond 4.4 am I right?
> 
> Thanks,
> Michael


If you look at lib/librte_eal/common/include/arch/x86/rte_vect.h, you'll see 
the code similar
to one you are trying to put into rte_shed.c:

lib/librte_eal/common/include/arch/x86/rte_vect.h:
...
#if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))

#ifdef __SSE__
#include 
#endif

#ifdef __SSE2__
#include 
#endif

#ifdef __SSE3__
#include 
#endif

#if defined(__SSE4_2__) || defined(__SSE4_1__)
#include 
#endif

#if defined(__AVX__)
#include 
#endif

#else

#include 

#endif
...

So I think you can do just like that:

#include 
#if defined(__AVX__)
#define SCHED_VECTOR_ENABLE
#endif

inside rte_sched.c

Konstantin


> 
> 
> > ? 2015?11?275:01?Thomas Monjalon  ???
> >
> > 2015-11-27 02:26, Qiu, Michael:
> >>> On 2015/11/27 5:29, Thomas Monjalon wrote:
> >>> 2015-11-26 18:49, Michael Qiu:
>  gcc 4.3.4 does not include "immintrin.h", and will post below error:
> lib/librte_sched/rte_sched.c:56:23: error:
> immintrin.h: No such file or directory
> 
>  To avoid this issue, a gcc version check is need and a flag to indicate
>  vector ablility.
> >>> [...]
>  +#if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
>  +
>  +#if defined(__AVX__)
>  #include 
>  +#define SCHED_VECTOR_ENABLE
>  +#endif
>  +
>  +#else
>  +
>  +#include 
>  +#define SCHED_VECTOR_ENABLE
>  +
>  +#endif
> >>> This kind of complication is managed by EAL.
> >>> I think we should include rte_vect.h.
> >>
> >> As I know here it needs a flag to identify whether the platform support
> >> AVX, if not it will not use it, so I don't know if we could only simply
> >> include rte_vect.h?
> >
> > It's not exclusive.
> > You can include rte_vect.h and check AVX to define SCHED_VECTOR_ENABLE.
> >

[dpdk-dev] [PATCH 1/2 v2] examples/distributor: Fix compile issue

[De Lara Guarch, Pablo]

> -Original Message-
> From: Qiu, Michael
> Sent: Friday, November 27, 2015 3:36 AM
> To: dev at dpdk.org
> Cc: De Lara Guarch, Pablo; thomas.monjalon at 6wind.com; Qiu, Michael
> Subject: [PATCH 1/2 v2] examples/distributor: Fix compile issue
> 
> examples/distributor/main.c(338): error #167:
> argument of type "struct rte_mbuf *"
> is incompatible with parameter of type "const char *"
>   _mm_prefetch(bufs[0], 0);
> 
> The first param pass to _mm_prefetch is wrong,
> need convert "struct rte_mbuf *" to "void *".
> 
> Fixes: 07db4a975094 ("examples/distributor: new sample app")
> 
> Signed-off-by: Michael Qiu 

Acked-by: Pablo de Lara 

[dpdk-dev] [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4

[Qiu, Michael]

really?I don't think so.

AVX Marco only exist in the gcc version below 4.4,  I still need to check if 
below or beyond 4.4 am I right?

Thanks,
Michael


> ? 2015?11?275:01?Thomas Monjalon  ???
> 
> 2015-11-27 02:26, Qiu, Michael:
>>> On 2015/11/27 5:29, Thomas Monjalon wrote:
>>> 2015-11-26 18:49, Michael Qiu:
 gcc 4.3.4 does not include "immintrin.h", and will post below error:
lib/librte_sched/rte_sched.c:56:23: error:
immintrin.h: No such file or directory
 
 To avoid this issue, a gcc version check is need and a flag to indicate
 vector ablility.
>>> [...]
 +#if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
 +
 +#if defined(__AVX__)
 #include 
 +#define SCHED_VECTOR_ENABLE
 +#endif
 +
 +#else
 +
 +#include 
 +#define SCHED_VECTOR_ENABLE
 +
 +#endif
>>> This kind of complication is managed by EAL.
>>> I think we should include rte_vect.h.
>> 
>> As I know here it needs a flag to identify whether the platform support
>> AVX, if not it will not use it, so I don't know if we could only simply
>> include rte_vect.h?
> 
> It's not exclusive.
> You can include rte_vect.h and check AVX to define SCHED_VECTOR_ENABLE.
> 

[dpdk-dev] [PATCH 2/2 v2] Fix compile issue in i686 platform

[Michael Qiu]

In i686 platform, long is 32bit, so XXX_CYCLECOUNTER_MASK
need define as 'ULL'

Fixes: 9c857bf6be87 ("igb: support ieee1588 functions for device time")
Fixes: 1c4445e1f28e ("ixgbe: support ieee1588 functions for device time")
Fixes: f3a4e40eca0c ("i40e: support ieee1588 functions for device time")

Signed-off-by: Michael Qiu 
---
v2 --> v1:
add "Fixes" line in commit log

 drivers/net/e1000/igb_ethdev.c   | 2 +-
 drivers/net/i40e/i40e_ethdev.c   | 2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 31452ae..518b6c9 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -78,7 +78,7 @@
 #define IGB_8_BIT_MASK   UINT8_MAX

 /* Additional timesync values. */
-#define E1000_CYCLECOUNTER_MASK  0x
+#define E1000_CYCLECOUNTER_MASK  0xULL
 #define E1000_ETQF_FILTER_1588   3
 #define IGB_82576_TSYNC_SHIFT16
 #define E1000_INCPERIOD_82576(1 << E1000_TIMINCA_16NS_SHIFT)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 13ab81a..5cd6e88 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -131,7 +131,7 @@
 #define I40E_PTP_1GB_INCVAL  0x20ULL
 #define I40E_PRTTSYN_TSYNENA 0x8000
 #define I40E_PRTTSYN_TSYNTYPE0x0e00
-#define I40E_CYCLECOUNTER_MASK   0x
+#define I40E_CYCLECOUNTER_MASK   0xULL

 #define I40E_MAX_PERCENT100
 #define I40E_DEFAULT_DCB_APP_NUM1
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 49f2410..808ac69 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -136,7 +136,7 @@
 #define IXGBE_INCVAL_SHIFT_82599 7
 #define IXGBE_INCPER_SHIFT_82599 24

-#define IXGBE_CYCLECOUNTER_MASK   0x
+#define IXGBE_CYCLECOUNTER_MASK   0xULL

 static int eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev);
 static int eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev);
-- 
1.9.3

[dpdk-dev] [PATCH 1/2 v2] examples/distributor: Fix compile issue

[Michael Qiu]

examples/distributor/main.c(338): error #167:
argument of type "struct rte_mbuf *"
is incompatible with parameter of type "const char *"
_mm_prefetch(bufs[0], 0);

The first param pass to _mm_prefetch is wrong,
need convert "struct rte_mbuf *" to "void *".

Fixes: 07db4a975094 ("examples/distributor: new sample app")

Signed-off-by: Michael Qiu 
---
v2 --> v1:
convert "const void *" to "void *" to avoid CLANG issue.
add "Fixes" line in commit log
 examples/distributor/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/examples/distributor/main.c b/examples/distributor/main.c
index 972bddb..a4d8e34 100644
--- a/examples/distributor/main.c
+++ b/examples/distributor/main.c
@@ -335,13 +335,13 @@ lcore_tx(struct rte_ring *in_r)

/* for traffic we receive, queue it up for transmit */
uint16_t i;
-   _mm_prefetch(bufs[0], 0);
-   _mm_prefetch(bufs[1], 0);
-   _mm_prefetch(bufs[2], 0);
+   _mm_prefetch((void *)bufs[0], 0);
+   _mm_prefetch((void *)bufs[1], 0);
+   _mm_prefetch((void *)bufs[2], 0);
for (i = 0; i < nb_rx; i++) {
struct output_buffer *outbuf;
uint8_t outp;
-   _mm_prefetch(bufs[i + 3], 0);
+   _mm_prefetch((void *)bufs[i + 3], 0);
/*
 * workers should update in_port to hold the
 * output port value
-- 
1.9.3

[dpdk-dev] [PATCH] config: disable CONFIG_RTE_SCHED_VECTOR for arm

[Thomas Monjalon]

Hi Jerin,

2015-11-27 15:23, Jerin Jacob:
> Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
> does support only SSE intrinsic, so disable it till we have neon support.
> 
> Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")
> 
> Signed-off-by: Jerin Jacob 
> ---
>  config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
>  config/defconfig_arm64-armv8a-linuxapp-gcc   | 1 +
>  config/defconfig_arm64-thunderx-linuxapp-gcc | 1 +
>  config/defconfig_arm64-xgene1-linuxapp-gcc   | 1 +

You would not need to update 4 files if the 3 last ones were including the
first one.
I think having an arm config base would also make clearer the differences
between the arm platforms.

[dpdk-dev] [PATCH] distributor: fix compilation on icc 2015

[De Lara Guarch, Pablo]

Hi Thomas,

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, November 27, 2015 10:10 AM
> To: De Lara Guarch, Pablo
> Cc: dev at dpdk.org; Qiu, Michael
> Subject: Re: [dpdk-dev] [PATCH] distributor: fix compilation on icc 2015
> 
> 2015-11-27 09:49, Pablo de Lara:
> > Fix following error on icc 2015:
> >
> >   CC main.o
> > /tmp/dpdk-tmp3/examples/distributor/main.c(338): error #167:
> >   argument of type "struct rte_mbuf *" is incompatible with
> >   parameter of type "const char *"
> > _mm_prefetch(bufs[0], 0);
> >
> > Fixes: 07db4a97 ("examples/distributor: new sample app")
> >
> > Reported-by: Yongjie Gu 
> > Signed-off-by: Pablo de Lara 
> 
> Hi Pablo,
> 
> It is the same patch as the first one of Michael which fails with clang:
>   http://dpdk.org/ml/archives/dev/2015-November/028929.html
> He has sent a second one without "const".

Oh yes, didn't see it, sorry about that.
Actually, it is strange that clang complains with const,
but not in virtio_rxtx_simple.c, where we use (const void *) in _mm_prefetch.
So, NACK to this patch and I will ack the other one.

[dpdk-dev] [PATCH v9 1/9] nfp: basic initialization

[Thomas Monjalon]

2015-11-27 07:51, Alejandro Lucero:
> I converted (almost) all the Linux typedefs. This one went under the radar.
> 
> We do not have such thing like ixgbe/base but maybe it makes sense.
> 
> Should I send a new patchset version for fixing this "minor nit"?

If you send a new version, please fix the MAINTAINERS file update
(and squash the change with the doc patch).

PS: please answer below instead of top post.


> On Thu, Nov 26, 2015 at 6:14 PM, Stephen Hemminger <
> stephen at networkplumber.org> wrote:
> 
> > On Thu, 26 Nov 2015 09:49:21 +
> > Alejandro Lucero  wrote:
> >
> > > +static inline void
> > > +nfp_qcp_ptr_add(__u8 *q, enum nfp_qcp_ptr ptr, uint32_t val)
> > > +{
> > > + uint32_t off;
> >
> > Minor nit. why mix use of Linux specific basic size typedefs (__u8)
> > with Posix standard values (uint32_t). The DPDK style is to use
> > the Posix types except in kernel drivers or code that is coming
> > from unified drivers (ie ixgbe/base)
> >

[dpdk-dev] [PATCH] hash: add rte_hash_set_cmp_func() function.

[Yu Nemo Wenbin]

Give user a chance to customize the hash key compare function.
The default rte_hash_cmp_eq function is set in the rte_hash_create
function, but these builtin ones may not be good enough, so the user
may call this to override the default one.

Signed-off-by: Yu Nemo Wenbin 
---
 lib/librte_hash/rte_cuckoo_hash.c|  7 +--
 lib/librte_hash/rte_hash.h   | 15 +++
 lib/librte_hash/rte_hash_version.map |  7 +++
 3 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/lib/librte_hash/rte_cuckoo_hash.c 
b/lib/librte_hash/rte_cuckoo_hash.c
index 88f77c3..2ccb81c 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -102,8 +102,6 @@ EAL_REGISTER_TAILQ(rte_hash_tailq)

 #define LCORE_CACHE_SIZE   8

-typedef int (*rte_hash_cmp_eq_t)(const void *key1, const void *key2, size_t 
key_len);
-
 struct lcore_cache {
unsigned len; /**< Cache len */
void *objs[LCORE_CACHE_SIZE]; /**< Cache objects */
@@ -187,6 +185,11 @@ rte_hash_find_existing(const char *name)
return h;
 }

+void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t func)
+{
+h->rte_hash_cmp_eq = func;
+}
+
 struct rte_hash *
 rte_hash_create(const struct rte_hash_parameters *params)
 {
diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h
index b678766..dfca5ef 100644
--- a/lib/librte_hash/rte_hash.h
+++ b/lib/librte_hash/rte_hash.h
@@ -66,6 +66,9 @@ typedef uint32_t hash_sig_t;
 typedef uint32_t (*rte_hash_function)(const void *key, uint32_t key_len,
  uint32_t init_val);

+/** Type of function used to compare the hash key. */
+typedef int (*rte_hash_cmp_eq_t)(const void *key1, const void *key2, size_t 
key_len);
+
 /**
  * Parameters used when creating the hash table.
  */
@@ -104,6 +107,18 @@ struct rte_hash *
 rte_hash_create(const struct rte_hash_parameters *params);

 /**
+ * Set the rte_hash_set_cmp_func.
+ * Set a new hash compare function other than the default one.
+ *
+ * @note Function pointer does not work with multi-process, so don't use it
+ * in multi-process mode.
+ *
+ * @param h
+ *   Hash table to reset
+ */
+void rte_hash_set_cmp_func(struct rte_hash *h, rte_hash_cmp_eq_t func);
+
+/**
  * Find an existing hash table object and return a pointer to it.
  *
  * @param name
diff --git a/lib/librte_hash/rte_hash_version.map 
b/lib/librte_hash/rte_hash_version.map
index 906c8ad..1aa94f9 100644
--- a/lib/librte_hash/rte_hash_version.map
+++ b/lib/librte_hash/rte_hash_version.map
@@ -32,3 +32,10 @@ DPDK_2.1 {
rte_hash_reset;

 } DPDK_2.0;
+
+DPDK_2.2 {
+   global:
+
+   rte_hash_set_cmp_func;
+
+} DPDK_2.1;
-- 
1.9.1

[dpdk-dev] [PATCH 2/2 v2] Fix compile issue in i686 platform

[Thomas Monjalon]

2015-11-27 11:36, Michael Qiu:
> In i686 platform, long is 32bit, so XXX_CYCLECOUNTER_MASK
> need define as 'ULL'

Michael, it is the same comment as the first patch.
How your compiler is different of mine which compiles fine without this patch?
I'm using GCC 5.2.0.

[dpdk-dev] [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4

[Thomas Monjalon]

2015-11-27 02:26, Qiu, Michael:
> On 2015/11/27 5:29, Thomas Monjalon wrote:
> > 2015-11-26 18:49, Michael Qiu:
> >> gcc 4.3.4 does not include "immintrin.h", and will post below error:
> >> lib/librte_sched/rte_sched.c:56:23: error:
> >> immintrin.h: No such file or directory
> >>
> >> To avoid this issue, a gcc version check is need and a flag to indicate
> >> vector ablility.
> > [...]
> >> +#if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
> >> +
> >> +#if defined(__AVX__)
> >>  #include 
> >> +#define SCHED_VECTOR_ENABLE
> >> +#endif
> >> +
> >> +#else
> >> +
> >> +#include 
> >> +#define SCHED_VECTOR_ENABLE
> >> +
> >> +#endif
> > This kind of complication is managed by EAL.
> > I think we should include rte_vect.h.
> 
> As I know here it needs a flag to identify whether the platform support
> AVX, if not it will not use it, so I don't know if we could only simply
> include rte_vect.h?

It's not exclusive.
You can include rte_vect.h and check AVX to define SCHED_VECTOR_ENABLE.

[dpdk-dev] [PATCH] fm10k: fix wrong Rx func is used

[Chen Jing D(Mark)]

From: "Chen Jing D(Mark)" 

Steps to reproduce the bug:
1. All Rx offloading is disabled and start the device, then
   Vector Rx is used.
2. Stop the device. Re-configure to enable hw_ip_checksum = 1,
   start the device again.
3. In this case, assume regular Rx should be used since Vector
   Rx doesn't support ip checksum offload. But actually Vector
   Rx is used and cause checksum won't be done by hardware.

The reason is after re-configuring, driver misses an "else" in
func fm10k_set_rx_function(). Then Rx func in last round are
used.

Fixes:77a8ab47("fm10k: select best Rx function")

Reported-by: Xiao Wang 
Signed-off-by: Chen Jing D(Mark) 
---
 drivers/net/fm10k/fm10k_ethdev.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 4f23ce3..e4aed94 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -2486,6 +2486,8 @@ fm10k_set_rx_function(struct rte_eth_dev *dev)
dev->rx_pkt_burst = fm10k_recv_pkts_vec;
} else if (dev->data->scattered_rx)
dev->rx_pkt_burst = fm10k_recv_scattered_pkts;
+   else
+   dev->rx_pkt_burst = fm10k_recv_pkts;

rx_using_sse =
(dev->rx_pkt_burst == fm10k_recv_scattered_pkts_vec ||
-- 
1.7.7.6

[dpdk-dev] [PATCH v2] fm10k: add debug info for actual Rx/Tx func

[Chen Jing D(Mark)]

From: "Chen Jing D(Mark)" 

After introducing vPMD feature, fm10k driver will select best
Rx/Tx in running time. Original implementation selects Rx/Tx
silently without notifications.

This patch adds debug info to notify user what actual Rx/Tx
func are used.

Signed-off-by: Chen Jing D(Mark) 
---
 drivers/net/fm10k/fm10k_ethdev.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 0dd56d2..4f23ce3 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -2458,13 +2458,16 @@ fm10k_set_tx_function(struct rte_eth_dev *dev)
}

if (use_sse) {
+   PMD_INIT_LOG(DEBUG, "Use vector Tx func");
for (i = 0; i < dev->data->nb_tx_queues; i++) {
txq = dev->data->tx_queues[i];
fm10k_txq_vec_setup(txq);
}
dev->tx_pkt_burst = fm10k_xmit_pkts_vec;
-   } else
+   } else {
dev->tx_pkt_burst = fm10k_xmit_pkts;
+   PMD_INIT_LOG(DEBUG, "Use regular Tx func");
+   }
 }

 static void __attribute__((cold))
@@ -2488,6 +2491,11 @@ fm10k_set_rx_function(struct rte_eth_dev *dev)
(dev->rx_pkt_burst == fm10k_recv_scattered_pkts_vec ||
dev->rx_pkt_burst == fm10k_recv_pkts_vec);

+   if (rx_using_sse)
+   PMD_INIT_LOG(DEBUG, "Use vector Rx func");
+   else
+   PMD_INIT_LOG(DEBUG, "Use regular Rx func");
+
for (i = 0; i < dev->data->nb_rx_queues; i++) {
struct fm10k_rx_queue *rxq = dev->data->rx_queues[i];

-- 
1.7.7.6

[dpdk-dev] [PATCH] distributor: fix compilation on icc 2015

[Pablo de Lara]

Fix following error on icc 2015:

  CC main.o
/tmp/dpdk-tmp3/examples/distributor/main.c(338): error #167:
  argument of type "struct rte_mbuf *" is incompatible with
  parameter of type "const char *"
_mm_prefetch(bufs[0], 0);

Fixes: 07db4a97 ("examples/distributor: new sample app")

Reported-by: Yongjie Gu 
Signed-off-by: Pablo de Lara 
---
 examples/distributor/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/examples/distributor/main.c b/examples/distributor/main.c
index 972bddb..a4d8e34 100644
--- a/examples/distributor/main.c
+++ b/examples/distributor/main.c
@@ -335,13 +335,13 @@ lcore_tx(struct rte_ring *in_r)

/* for traffic we receive, queue it up for transmit */
uint16_t i;
-   _mm_prefetch(bufs[0], 0);
-   _mm_prefetch(bufs[1], 0);
-   _mm_prefetch(bufs[2], 0);
+   _mm_prefetch((const void *)bufs[0], 0);
+   _mm_prefetch((const void *)bufs[1], 0);
+   _mm_prefetch((const void *)bufs[2], 0);
for (i = 0; i < nb_rx; i++) {
struct output_buffer *outbuf;
uint8_t outp;
-   _mm_prefetch(bufs[i + 3], 0);
+   _mm_prefetch((const void *)bufs[i + 3], 0);
/*
 * workers should update in_port to hold the
 * output port value
-- 
2.5.0

[dpdk-dev] [PATCH v9 1/9] nfp: basic initialization

[Alejandro Lucero]

I converted (almost) all the Linux typedefs. This one went under the radar.

We do not have such thing like ixgbe/base but maybe it makes sense.

Should I send a new patchset version for fixing this "minor nit"?

Thanks

On Thu, Nov 26, 2015 at 6:14 PM, Stephen Hemminger <
stephen at networkplumber.org> wrote:

> On Thu, 26 Nov 2015 09:49:21 +
> Alejandro Lucero  wrote:
>
> > +static inline void
> > +nfp_qcp_ptr_add(__u8 *q, enum nfp_qcp_ptr ptr, uint32_t val)
> > +{
> > + uint32_t off;
>
> Minor nit. why mix use of Linux specific basic size typedefs (__u8)
> with Posix standard values (uint32_t). The DPDK style is to use
> the Posix types except in kernel drivers or code that is coming
> from unified drivers (ie ixgbe/base)
>

[dpdk-dev] [PATCH v6 0/8] virtio ring layout optimization and simple rx/tx processing

[Xu, Qian Q]

Some virtio-pmd optimization performance data sharing: 
1. Use simplified vhost-sample, only doing the dequeuer and free, so virtio 
only tx, then test the virtio tx performance improvement. Then in the VM, using 
one virtio to do the txonly, and let the virtio tx working. Also modified the 
txonly file to remove the memory copy part, then check the virtio TX rate. The 
performance of optimized virtio-pmd will have ~2x performance than the 
non-optimized virtio-pmd. 
2. Similarly as item1, but use the default txonly file, so with memory copy, 
then the performance of optimized virtio-pmd will have ~37% performance 
improvement than the non-optimized virtio-pmd. 
3. In the OVS test scenario, one physical NIC + one virtio in the VM, then let 
the virtio do the loopback(having rx and tx), running testpmd in the VM, then 
the performance will have 60% performance improvement than the non-optimized 
virtio-pmd. 



Thanks
Qian

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Huawei Xie
Sent: Thursday, October 29, 2015 10:53 PM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v6 0/8] virtio ring layout optimization and simple 
rx/tx processing

Changes in v6:
- Update release notes
- Fix the error in virtio tx ring layout ascii chart in the cover-letter

Changes in v5:
- Call __rte_pktmbuf_prefree_seg to check refcnt when free mbufs

Changes in v4:
- Fix the error in virtio tx ring layout ascii chart in the commit message
- Move virtio_xmit_cleanup ahead to free descriptors earlier
- Test merge-able feature when select simple rx/tx functions

Changes in v3:
- Remove unnecessary NULL test for rte_free
- Remove unnecessary assign of local var after free
- Remove return at the end of void function
- Remove always_inline attribute for virtio_xmit_cleanup
- Reword some commit messages
- Add TODO in the commit message of simple tx patch

Changes in v2:
- Remove the configure macro
- Enable simple R/TX processing when user specifies simple txq flags
- Reword some comments and commit messages

In DPDK based switching enviroment, mostly vhost runs on a dedicated core while 
virtio processing in guest VMs runs on other different cores.
Take RX for example, with generic implementation, for each guest buffer,
a) virtio driver allocates a descriptor from free descriptor list
b) modify the entry of avail ring to point to allocated descriptor
c) after packet is received, free the descriptor

When vhost fetches the avail ring, it need to fetch the modified L1 cache from 
virtio core, which is a heavy cost in current CPU implementation.

This idea of this optimization is:
allocate the fixed descriptor for each entry of avail ring, so avail ring 
will always be the same during the run.
This removes L1M cache transfer from virtio core to vhost core for avail ring.
(Note we couldn't avoid the cache transfer for descriptors).
Besides, descriptor allocation and free operation is eliminated.
This also makes vector procesing possible to further accelerate the processing.

This is the layout for the avail ring(take 256 ring entries for example), with 
each entry pointing to the descriptor with the same index.
avail
idx
+
|
+++---+-+--+
| 0  | 1  | 2 | ... |  254  | 255  |  avail ring
+-+--+-+--+-+-+-+---+--+---+
  |||   |   |  |
  |||   |   |  |
  vvv   |   v  v
+-+--+-+--+-+-+-+---+--+---+
| 0  | 1  | 2 | ... |  254  | 255  |  desc ring
+++---+-+--+
|
|
+++---+-+--+
| 0  | 1  | 2 | |  254  | 255  |  used ring
+++---+-+--+
|
+

This is the ring layout for TX.
As we need one virtio header for each xmit packet, we have 128 slots available.

 ++
 ||
 ||
+-+-+-+--+--+--+--+
|  0  |  1  | ... |  127 || 128  | 129  | ...  | 255  |   avail ring
+--+--+--+--+-+---+--+---+--+---+--+--+---+
   | ||  ||  |  | |
   v vv  ||  v  v v
+--+--+--+--+-+---+--+---+--+---+--+--+---+
| 128 | 129 | ... |  255 || 127  | 128  | ...  | 255  |   desc ring for 
virtio_net_hdr
+--+--+--+--+-+---+--+---+--+---+--+--+---+
   | ||  ||  |  | |
   v vv  ||  v  v v
+--+--+--+--+-+---+--+---+--+---+--+--+---+
|  0  |  1  | ... |  127 ||  0   |  1   | ...  | 127  |   desc ring for tx dat
+-+-+-+--+--+--+--+
 ||
 ||
 ++


Performance boost could be observed only if the virtio backend isn't the 
bottleneck or in VM2VM case.
There are 

[dpdk-dev] [PATCH] fm10k: fix wrong Rx func is used

[Wang, Xiao W]

Hi,

> -Original Message-
> From: Chen, Jing D
> Sent: Friday, November 27, 2015 9:56 AM
> To: dev at dpdk.org
> Cc: Wang, Xiao W ; Chen, Jing D
> 
> Subject: [PATCH] fm10k: fix wrong Rx func is used
> 
> From: "Chen Jing D(Mark)" 
> 
> Steps to reproduce the bug:
> 1. All Rx offloading is disabled and start the device, then
>Vector Rx is used.
> 2. Stop the device. Re-configure to enable hw_ip_checksum = 1,
>start the device again.
> 3. In this case, assume regular Rx should be used since Vector
>Rx doesn't support ip checksum offload. But actually Vector
>Rx is used and cause checksum won't be done by hardware.
> 
> The reason is after re-configuring, driver misses an "else" in func
> fm10k_set_rx_function(). Then Rx func in last round are used.
> 
> Fixes:77a8ab47("fm10k: select best Rx function")
> 
> Reported-by: Xiao Wang 
> Signed-off-by: Chen Jing D(Mark) 
> ---
>  drivers/net/fm10k/fm10k_ethdev.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/fm10k/fm10k_ethdev.c
> b/drivers/net/fm10k/fm10k_ethdev.c
> index 4f23ce3..e4aed94 100644
> --- a/drivers/net/fm10k/fm10k_ethdev.c
> +++ b/drivers/net/fm10k/fm10k_ethdev.c
> @@ -2486,6 +2486,8 @@ fm10k_set_rx_function(struct rte_eth_dev *dev)
>   dev->rx_pkt_burst = fm10k_recv_pkts_vec;
>   } else if (dev->data->scattered_rx)
>   dev->rx_pkt_burst = fm10k_recv_scattered_pkts;
> + else
> + dev->rx_pkt_burst = fm10k_recv_pkts;
> 
>   rx_using_sse =
>   (dev->rx_pkt_burst == fm10k_recv_scattered_pkts_vec ||
> --
> 1.7.7.6
Acked-by: Xiao Wang 

[dpdk-dev] [PATCH] lib/librte_sched: Fix compile with gcc 4.3.4

[Qiu, Michael]

On 2015/11/27 5:29, Thomas Monjalon wrote:
> 2015-11-26 18:49, Michael Qiu:
>> gcc 4.3.4 does not include "immintrin.h", and will post below error:
>> lib/librte_sched/rte_sched.c:56:23: error:
>> immintrin.h: No such file or directory
>>
>> To avoid this issue, a gcc version check is need and a flag to indicate
>> vector ablility.
> [...]
>> +#if (defined(__ICC) || (__GNUC__ == 4 &&  __GNUC_MINOR__ < 4))
>> +
>> +#if defined(__AVX__)
>>  #include 
>> +#define SCHED_VECTOR_ENABLE
>> +#endif
>> +
>> +#else
>> +
>> +#include 
>> +#define SCHED_VECTOR_ENABLE
>> +
>> +#endif
> This kind of complication is managed by EAL.
> I think we should include rte_vect.h.

As I know here it needs a flag to identify whether the platform support
AVX, if not it will not use it, so I don't know if we could only simply
include rte_vect.h?

Thanks,
Michael
>
>

[dpdk-dev] [PATCH] distributor: fix compilation on icc 2015

[Thomas Monjalon]

2015-11-27 09:49, Pablo de Lara:
> Fix following error on icc 2015:
> 
>   CC main.o
> /tmp/dpdk-tmp3/examples/distributor/main.c(338): error #167:
>   argument of type "struct rte_mbuf *" is incompatible with
>   parameter of type "const char *"
> _mm_prefetch(bufs[0], 0);
> 
> Fixes: 07db4a97 ("examples/distributor: new sample app")
> 
> Reported-by: Yongjie Gu 
> Signed-off-by: Pablo de Lara 

Hi Pablo,

It is the same patch as the first one of Michael which fails with clang:
http://dpdk.org/ml/archives/dev/2015-November/028929.html
He has sent a second one without "const".

[dpdk-dev] [PATCH 2/2] Fix compile issue in i686 platform

[Qiu, Michael]

On 2015/11/27 5:15, Thomas Monjalon wrote:
> 2015-11-26 09:35, Michael Qiu:
>> In i686 platform, long is 32bit, so XXX_CYCLECOUNTER_MASK
>> need define as 'ULL'
>>
>> Signed-off-by: Michael Qiu 
> This patch is correct but the description is not exact:
> I have no issue with my i686 compiler.
> For future reference, please could you be more precise
> about the reproduction environment? Is it related to a specific compiler?

OK, I will be for careful about the compile and os next time.

> We also need to add these lines:
> Fixes: 9c857bf6be87 ("igb: support ieee1588 functions for device time")
> Fixes: 1c4445e1f28e ("ixgbe: support ieee1588 functions for device time")
> Fixes: f3a4e40eca0c ("i40e: support ieee1588 functions for device time")

So I will repost the patch set.

Thanks,
Michael

[dpdk-dev] [PATCH 1/2] examples/distributor: Fix compile issue

[Wan, Qun]

Acked and verified.

-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Michael Qiu
Sent: Thursday, November 26, 2015 9:35 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH 1/2] examples/distributor: Fix compile issue

examples/distributor/main.c(338): error #167:
argument of type "struct rte_mbuf *"
is incompatible with parameter of type "const char *"
_mm_prefetch(bufs[0], 0);

The first param of _mm_prefetch should be "const char *" and need convert 
"struct rte_mbuf *" to "const void *".

Signed-off-by: Michael Qiu 
---
 examples/distributor/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/examples/distributor/main.c b/examples/distributor/main.c index 
972bddb..a4d8e34 100644
--- a/examples/distributor/main.c
+++ b/examples/distributor/main.c
@@ -335,13 +335,13 @@ lcore_tx(struct rte_ring *in_r)

/* for traffic we receive, queue it up for transmit */
uint16_t i;
-   _mm_prefetch(bufs[0], 0);
-   _mm_prefetch(bufs[1], 0);
-   _mm_prefetch(bufs[2], 0);
+   _mm_prefetch((const void *)bufs[0], 0);
+   _mm_prefetch((const void *)bufs[1], 0);
+   _mm_prefetch((const void *)bufs[2], 0);
for (i = 0; i < nb_rx; i++) {
struct output_buffer *outbuf;
uint8_t outp;
-   _mm_prefetch(bufs[i + 3], 0);
+   _mm_prefetch((const void *)bufs[i + 3], 0);
/*
 * workers should update in_port to hold the
 * output port value
--
1.9.3