[dpdk-dev] [PATCH] examples/vm_power_manager: fix build when libvirt version < 1.0
2015-12-07 15:24, Yong Liu: > virNodeGetCPUMap introduced in from libvirt 1.0. In some linux distributions > like Ubuntu12/14 and Fedora18, libvirt version is elder than 1.0. So this > sample will not build pass. > > Replace "virNodeGetCPUMap" with another libvirt API "virNodeGetInfo". > > Signed-off-by: Marvin Liu Applied, thanks
[dpdk-dev] [PATCH v2] scripts: support any legal git revisions as abi validation range
2015-12-03 16:05, Panu Matilainen: > In addition to git tags, support validating abi between any legal > gitrevisions(7) syntaxes, such as "validate-abi.sh -1 . " > "validate-abi.sh master mybranch " etc in addition to > validating between tags. Makes it easier to run the validator > for in-development work. > > Signed-off-by: Panu Matilainen > Acked-by: Neil Horman Applied, thanks
[dpdk-dev] [PATCH v3 06/13] mk: split install rule
Hi Thomas,
I'm testing this set of patches that has been applied, and I haven't noticed
before
that you exclude some binaries in "install-runtime" (test, testpipeline,
testacl etc...), I would like
to ask you the reason about this :)
Thanks.
Mario.
From: Thomas Monjalon [thomas.monja...@6wind.com]
Sent: Thursday, December 03, 2015 5:45 AM
To: dev at dpdk.org
Cc: olivier.matz at 6wind.com; Arevalo, Mario Alfredo C; Richardson, Bruce;
Panu Matilainen
Subject: [PATCH v3 06/13] mk: split install rule
Provides new sub-rules to install runtime and sdk separately.
The build directory must be changed from BUILD_DIR to O in install
rules to avoid a bad recursive effect (O being BUILD_DIR being O + T).
Suggested-by: Mario Carrillo
Signed-off-by: Thomas Monjalon
Acked-by: Panu Matilainen
---
mk/rte.sdkinstall.mk | 18 --
mk/rte.sdkroot.mk| 2 ++
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index dc57baf..ec093d3 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -93,25 +93,31 @@ ifeq ($(DESTDIR)$(if $T,,+),)
@echo Installation cannot run with T defined and DESTDIR undefined
else
@echo == Installing $(DESTDIR)$(prefix)/
+ $(Q)$(MAKE) O=$(RTE_OUTPUT) T= install-runtime
+ $(Q)$(MAKE) O=$(RTE_OUTPUT) T= install-sdk
+ @echo Installation in $(DESTDIR)$(prefix)/ complete
+endif
+
+install-runtime:
$(Q)$(call rte_mkdir, $(DESTDIR)$(libdir))
- $(Q)cp -a $(RTE_OUTPUT)/lib/* $(DESTDIR)$(libdir)
+ $(Q)cp -a$O/lib/* $(DESTDIR)$(libdir)
$(Q)$(call rte_mkdir, $(DESTDIR)$(bindir))
- $(Q)tar -cf - -C $(RTE_OUTPUT) app --exclude 'app/*.map' \
+ $(Q)tar -cf - -C $O app --exclude 'app/*.map' \
--exclude 'app/cmdline*' --exclude app/test \
--exclude app/testacl --exclude app/testpipeline | \
tar -xf - -C $(DESTDIR)$(bindir) --strip-components=1 \
--keep-newer-files --warning=no-ignore-newer
$(Q)$(call rte_mkdir, $(DESTDIR)$(datadir))
$(Q)cp -a $(RTE_SDK)/tools $(DESTDIR)$(datadir)
+
+install-sdk:
$(Q)$(call rte_mkdir, $(DESTDIR)$(includedir))
- $(Q)tar -chf - -C $(RTE_OUTPUT) include | \
+ $(Q)tar -chf - -C $O include | \
tar -xf - -C $(DESTDIR)$(includedir) --strip-components=1 \
--keep-newer-files --warning=no-ignore-newer
$(Q)$(call rte_mkdir,$(DESTDIR)$(sdkdir))
$(Q)cp -a $(RTE_SDK)/{mk,scripts} $(DESTDIR)$(sdkdir)
$(Q)$(call rte_mkdir,$(DESTDIR)$(targetdir))
- $(Q)cp -a $(RTE_OUTPUT)/.config$(DESTDIR)$(targetdir)
+ $(Q)cp -a $O/.config $(DESTDIR)$(targetdir)
$(Q)$(call rte_symlink, $(DESTDIR)$(includedir),
$(DESTDIR)$(targetdir)/include)
$(Q)$(call rte_symlink, $(DESTDIR)$(libdir),
$(DESTDIR)$(targetdir)/lib)
- @echo Installation in $(DESTDIR)$(prefix)/ complete
-endif
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index 533afe9..2424dce 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,6 +97,8 @@ test fast_test ring_test mempool_test perf_test coverage:
install:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk pre_install
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
+install-%:
+ $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
doc: doc-all
--
2.5.2
[dpdk-dev] [PATCH v2] mk: fix external shared library dependencies of drivers, round 2
2015-12-07 14:58, Aaron Conole:
> Panu Matilainen writes:
> > Similar to commit 5f9115e58cc6f304ff4ade694cf5823d32887d1a, but
> > for qat and mpipe drivers. The former did not exist when the
> > previous patch was sent and latter I just missed.
> >
> > Fixes: 5f9115e58cc6 ("mk: fix shared library dependencies of drivers")
> >
> > Signed-off-by: Panu Matilainen
>
> Acked-by: Aaron Conole
Applied, thanks
[dpdk-dev] [PATCH 1/1] kni: Fix compilation problems on RHEL 7.2.
2015-12-07 07:59, Lee Roberts: > RHEL 7.2 contains additional backports from newer upstream kernels. > Add RHEL_RELEASE_CODE logic for RHEL_RELEASE_VERSION(7,2) to pick up > the changes to kernel functions. > > Signed-off-by: Lee Roberts Applied, thanks If there is a new error in coming days due to this patch, it will be too late to fix it for 2.2, so it could be reverted.
[dpdk-dev] [PATCH] mk: fix warning spew when EXTRA_CFLAGS specifies warning flags
2015-12-07 14:49, Simon K?gstr?m: > On 2015-12-07 13:56, Panu Matilainen wrote: > > Starting with commit 9aa2053c6e81493b23346ff4e387903560de5c81 > > EXTRA_CFLAGS is sometimes being passed to the compiler without > > WERROR_FLAGS which can cause spurious warnings by the dozen, > > for example with when compiling with EXTRA_CFLAGS="-Wformat-security": > > > > cc1: warning: -Wformat-security ignored without -Wformat [-Wformat-security] > > > > Passing WERROR_FLAGS to AUTO_CPU helper makes the warning flag usage > > consistent throughout the codebase, silencing the warnings. > > Acked-by: Simon Kagstrom Applied, thanks
[dpdk-dev] [PATCH v3 2/2] eal/linux: Add support for handling built-in kernel modules
On Mon, Dec 7, 2015 at 7:36 PM, Kamil Rytarowski <
Kamil.Rytarowski at caviumnetworks.com> wrote:
> Currently rte_eal_check_module() detects Linux kernel modules via reading
> /proc/modules. Built-in ones aren't listed there and therefore they are not
> being found by the script.
>
> Add support for checking built-in modules with parsing the sysfs files
>
> This commit obsoletes the /proc/modules parsing approach.
>
> Signed-off-by: Kamil Rytarowski
> ---
> lib/librte_eal/linuxapp/eal/eal.c | 32 +---
> 1 file changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal.c
> b/lib/librte_eal/linuxapp/eal/eal.c
> index 635ec36..539188f 100644
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -52,6 +52,8 @@
> #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
> #include
> #endif
> +#include
> +#include
>
> #include
> #include
> @@ -901,27 +903,27 @@ int rte_eal_has_hugepages(void)
> int
> rte_eal_check_module(const char *module_name)
> {
> - char mod_name[30]; /* Any module names can be longer than 30
> bytes? */
> - int ret = 0;
> - int n;
> + char sysfs_mod_name[PATH_MAX];
> + struct stat st;
>
> if (NULL == module_name)
> return -1;
>
> - FILE *fd = fopen("/proc/modules", "r");
> - if (NULL == fd) {
> - RTE_LOG(ERR, EAL, "Open /proc/modules failed!"
> - " error %i (%s)\n", errno, strerror(errno));
> + /* Check if there is sysfs mounted */
> + if (stat("/sys/module", ) != 0) {
> + RTE_LOG(DEBUG, EAL, "Open /sys/module failed: %s\n",
> + strerror(errno));
> return -1;
> }
>
Not sure making a difference between /sys/module and /sys/module/XXX
presence really helps, but this is the same philosophy as how it was done
before...
So, ok let's go with this.
> - while (!feof(fd)) {
> - n = fscanf(fd, "%29s %*[^\n]", mod_name);
> - if ((n == 1) && !strcmp(mod_name, module_name)) {
> - ret = 1;
> - break;
> - }
> +
> + /* A module might be built-in, therefore try sysfs */
> + snprintf(sysfs_mod_name, PATH_MAX, "/sys/module/%s", module_name);
> + if (stat(sysfs_mod_name, ) != 0) {
> + RTE_LOG(DEBUG, EAL, "Open %s failed! error %i (%s)\n",
> + sysfs_mod_name, errno, strerror(errno));
> + return 0;
> }
>
Please, add a check on snprintf return value.
Even if this can't happen, if snprintf fails, stat would access a truncated
or uninitialized (when < 0) path.
With this fixed, you can add my ack.
Thanks.
--
David Marchand
[dpdk-dev] [PATCH 0/2] fix performance/cache resource issues with 128-byte cache line targets
On Mon, Dec 07, 2015 at 03:40:13AM -0800, Thomas Monjalon wrote: > 2015-12-07 12:56, Jerin Jacob: > > On Sun, Dec 06, 2015 at 05:30:50PM +0100, Thomas Monjalon wrote: > > > 2015-12-06 21:29, Jerin Jacob: > > > > This patchset fixes performance/cache resource issues with 128-byte > > > > cache line targets > > > > found in mbuf and bitmap DPDK libraries > > > > > > > > Currently, we have two DPDK targets(ThunderX and ppc_64) which are > > > > based on > > > > 128-bytes cache line size target. > > > > > > When introducing IBM Power8, we failed to clean the cache line size > > > definition. > > > I promised to not forget this issue in this thread with Neil: > > > http://dpdk.org/ml/archives/dev/2014-December/009439.html > > > > > > It is defined in > > > config/defconfig_* > > > mk/machine/*/rte.vars.mk > > > mk/arch/*/rte.vars.mk > > > rte_memory.h > > > rte_kni_common.h > > > > > > It should be defined only in the config files. > > > When we will introduce a configure script, we should be able to detect it. > > > > > > Please Jerin, as ThunderX maintainer, may you help to fix this old mess? > > > > Yes Thomas, I will takeup this issue when we will have configure script. > > I thought we could start setting the value in only one place. > The detection in configure script would be another step. OK Thomas, I have sent the cleanup patch. Please review it. Jerin > > > apart from that, content of the this patch will be still valid > > as the fix going to be generating cache line define from the config file. > >
[dpdk-dev] [PATCH] config: cleanup existing RTE_CACHE_LINE_SIZE selection scheme
by default, all the targets will be configured with the 64-byte cache line
size, targets which have different cache line size can be overridden
through target specific config file.
Selected ThunderX and power8 as CONFIG_RTE_CACHE_LINE_SIZE=128 targets
based on existing configuration.
Signed-off-by: Jerin Jacob
---
config/common_bsdapp | 5 +
config/common_linuxapp| 6 +-
config/defconfig_arm64-armv8a-linuxapp-gcc| 2 --
config/defconfig_ppc_64-power8-linuxapp-gcc | 2 ++
lib/librte_eal/common/include/rte_memory.h| 3 ---
lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h | 4
mk/arch/arm/rte.vars.mk | 2 +-
mk/arch/ppc_64/rte.vars.mk| 2 +-
mk/machine/armv8a/rte.vars.mk | 2 +-
mk/machine/thunderx/rte.vars.mk | 2 +-
mk/machine/xgene1/rte.vars.mk | 2 +-
11 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/config/common_bsdapp b/config/common_bsdapp
index 3286481..5dbcc33 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -94,6 +94,11 @@ CONFIG_RTE_BUILD_COMBINE_LIBS=n
CONFIG_RTE_NEXT_ABI=y
#
+# Machine's cache line size
+#
+CONFIG_RTE_CACHE_LINE_SIZE=64
+
+#
# Compile Environment Abstraction Layer
#
CONFIG_RTE_LIBRTE_EAL=y
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 2866986..54168be 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -94,6 +94,11 @@ CONFIG_RTE_BUILD_COMBINE_LIBS=n
CONFIG_RTE_NEXT_ABI=y
#
+# Machine's cache line size
+#
+CONFIG_RTE_CACHE_LINE_SIZE=64
+
+#
# Compile Environment Abstraction Layer
#
CONFIG_RTE_LIBRTE_EAL=y
@@ -110,7 +115,6 @@ CONFIG_RTE_EAL_ALWAYS_PANIC_ON_ERROR=n
CONFIG_RTE_EAL_IGB_UIO=y
CONFIG_RTE_EAL_VFIO=y
CONFIG_RTE_MALLOC_DEBUG=n
-
# Default driver path (or "" to disable)
CONFIG_RTE_EAL_PMD_PATH=""
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc
b/config/defconfig_arm64-armv8a-linuxapp-gcc
index 57f7941..52e0c97 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -43,8 +43,6 @@ 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
diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc
b/config/defconfig_ppc_64-power8-linuxapp-gcc
index 03760c4..a80a19e 100644
--- a/config/defconfig_ppc_64-power8-linuxapp-gcc
+++ b/config/defconfig_ppc_64-power8-linuxapp-gcc
@@ -36,6 +36,8 @@ CONFIG_RTE_ARCH="ppc_64"
CONFIG_RTE_ARCH_PPC_64=y
CONFIG_RTE_ARCH_64=y
+CONFIG_RTE_CACHE_LINE_SIZE=128
+
CONFIG_RTE_TOOLCHAIN="gcc"
CONFIG_RTE_TOOLCHAIN_GCC=y
diff --git a/lib/librte_eal/common/include/rte_memory.h
b/lib/librte_eal/common/include/rte_memory.h
index 33f5a77..b697c90 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -68,9 +68,6 @@ enum rte_page_sizes {
};
#define SOCKET_ID_ANY -1/**< Any NUMA socket. */
-#ifndef RTE_CACHE_LINE_SIZE
-#define RTE_CACHE_LINE_SIZE 64 /**< Cache line size. */
-#endif
#define RTE_CACHE_LINE_MASK (RTE_CACHE_LINE_SIZE-1) /**< Cache line mask. */
#define RTE_CACHE_LINE_ROUNDUP(size) \
diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
index e724af7..cfd142a 100644
--- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
+++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
@@ -68,10 +68,6 @@
*/
#define RTE_KNI_NAMESIZE 32
-#ifndef RTE_CACHE_LINE_SIZE
-#define RTE_CACHE_LINE_SIZE 64 /**< Cache line size. */
-#endif
-
/*
* Request id.
*/
diff --git a/mk/arch/arm/rte.vars.mk b/mk/arch/arm/rte.vars.mk
index df0c043..bd85140 100644
--- a/mk/arch/arm/rte.vars.mk
+++ b/mk/arch/arm/rte.vars.mk
@@ -32,7 +32,7 @@
ARCH ?= arm
CROSS ?=
-CPU_CFLAGS ?= -marm -DRTE_CACHE_LINE_SIZE=64 -munaligned-access
+CPU_CFLAGS ?= -marm -munaligned-access
CPU_LDFLAGS ?=
CPU_ASFLAGS ?= -felf
diff --git a/mk/arch/ppc_64/rte.vars.mk b/mk/arch/ppc_64/rte.vars.mk
index fdba019..363fcd1 100644
--- a/mk/arch/ppc_64/rte.vars.mk
+++ b/mk/arch/ppc_64/rte.vars.mk
@@ -32,7 +32,7 @@
ARCH ?= powerpc
CROSS ?=
-CPU_CFLAGS ?= -m64 -DRTE_CACHE_LINE_SIZE=128
+CPU_CFLAGS ?= -m64
CPU_LDFLAGS ?=
CPU_ASFLAGS ?= -felf64
diff --git a/mk/machine/armv8a/rte.vars.mk b/mk/machine/armv8a/rte.vars.mk
index 8c018a4..d5049e1 100644
--- a/mk/machine/armv8a/rte.vars.mk
+++ b/mk/machine/armv8a/rte.vars.mk
@@ -55,4 +55,4 @@
# CPU_LDFLAGS =
# CPU_ASFLAGS =
-MACHINE_CFLAGS += -march=armv8-a+crc -DRTE_CACHE_LINE_SIZE=64
+MACHINE_CFLAGS +=
[dpdk-dev] [PATCH v3 2/2] eal/linux: Add support for handling built-in kernel modules
Currently rte_eal_check_module() detects Linux kernel modules via reading
/proc/modules. Built-in ones aren't listed there and therefore they are not
being found by the script.
Add support for checking built-in modules with parsing the sysfs files
This commit obsoletes the /proc/modules parsing approach.
Signed-off-by: Kamil Rytarowski
---
lib/librte_eal/linuxapp/eal/eal.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 635ec36..539188f 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -52,6 +52,8 @@
#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
#include
#endif
+#include
+#include
#include
#include
@@ -901,27 +903,27 @@ int rte_eal_has_hugepages(void)
int
rte_eal_check_module(const char *module_name)
{
- char mod_name[30]; /* Any module names can be longer than 30 bytes? */
- int ret = 0;
- int n;
+ char sysfs_mod_name[PATH_MAX];
+ struct stat st;
if (NULL == module_name)
return -1;
- FILE *fd = fopen("/proc/modules", "r");
- if (NULL == fd) {
- RTE_LOG(ERR, EAL, "Open /proc/modules failed!"
- " error %i (%s)\n", errno, strerror(errno));
+ /* Check if there is sysfs mounted */
+ if (stat("/sys/module", ) != 0) {
+ RTE_LOG(DEBUG, EAL, "Open /sys/module failed: %s\n",
+ strerror(errno));
return -1;
}
- while (!feof(fd)) {
- n = fscanf(fd, "%29s %*[^\n]", mod_name);
- if ((n == 1) && !strcmp(mod_name, module_name)) {
- ret = 1;
- break;
- }
+
+ /* A module might be built-in, therefore try sysfs */
+ snprintf(sysfs_mod_name, PATH_MAX, "/sys/module/%s", module_name);
+ if (stat(sysfs_mod_name, ) != 0) {
+ RTE_LOG(DEBUG, EAL, "Open %s failed! error %i (%s)\n",
+ sysfs_mod_name, errno, strerror(errno));
+ return 0;
}
- fclose(fd);
- return ret;
+ /* Module has been found */
+ return 1;
}
--
2.5.0
[dpdk-dev] [PATCH v3 1/2] tools: Add support for handling built-in kernel modules
Currently dpdk_nic_bind.py detects Linux kernel modules via reading
/proc/modules. Built-in ones aren't listed there and therefore they are not
being found by the script.
Add support for checking built-in modules with parsing the sysfs files.
This commit obsoletes the /proc/modules parsing approach.
Signed-off-by: Kamil Rytarowski
---
tools/dpdk_nic_bind.py | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/tools/dpdk_nic_bind.py b/tools/dpdk_nic_bind.py
index f02454e..0318598 100755
--- a/tools/dpdk_nic_bind.py
+++ b/tools/dpdk_nic_bind.py
@@ -33,7 +33,7 @@
#
import sys, os, getopt, subprocess
-from os.path import exists, abspath, dirname, basename
+from os.path import exists, abspath, dirname, basename, join
# The PCI device class for ETHERNET devices
@@ -156,22 +156,29 @@ def check_modules():
'''Checks that igb_uio is loaded'''
global dpdk_drivers
-fd = file("/proc/modules")
-loaded_mods = fd.readlines()
-fd.close()
-
# list of supported modules
mods = [{"Name" : driver, "Found" : False} for driver in dpdk_drivers]
# first check if module is loaded
-for line in loaded_mods:
+try:
+# Get list of syfs modules, some of them might be builtin and merge
with mods
+sysfs_path = '/sys/module/'
+
+# Get the list of directories in sysfs_path
+sysfs_mods = [os.path.join(sysfs_path,o) for o in
os.listdir(sysfs_path) if os.path.isdir(os.path.join(sysfs_path,o))]
+
+# Extract the last element of '/sys/module/abc' in the array
+sysfs_mods = [a.split('/')[-1] for a in sysfs_mods]
+
+# special case for vfio_pci (module is named vfio-pci,
+# but its .ko is named vfio_pci)
+sysfs_mods = map(lambda a: a if a != 'vfio_pci' else 'vfio-pci',
sysfs_mods)
+
for mod in mods:
-if line.startswith(mod["Name"]):
-mod["Found"] = True
-# special case for vfio_pci (module is named vfio-pci,
-# but its .ko is named vfio_pci)
-elif line.replace("_", "-").startswith(mod["Name"]):
+if mod["Found"] == False and (mod["Name"] in sysfs_mods):
mod["Found"] = True
+except:
+pass
# check if we have at least one loaded module
if True not in [mod["Found"] for mod in mods] and b_flag is not None:
--
2.5.0
[dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
On 12/07/2015 03:55 PM, Thomas Monjalon wrote: > 2015-12-07 13:41, Panu Matilainen: >> On 12/07/2015 01:28 PM, Thomas Monjalon wrote: >>> 2015-12-07 08:29, Panu Matilainen: On 12/07/2015 01:07 AM, Thomas Monjalon wrote: > 2015-12-02 15:53, Panu Matilainen: The vhost ABI break was announced for DPDK 2.2 in commit 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d: >>> [...] So the ABI process was properly followed, except for actually bumping LIBABIVER. Bumping LIBABIVER is mentioned in doc/guides/contributing/versioning.rst but it doesn't specify *when* this should be done, eg should the first patch breaking the ABI bump it or should it done be shortly before the next stable release, or something else. As it is, it seems a bit too easy to simply forget. >>> >>> I thought it was not needed to explicitly say that commits must be atomic >>> and we do not have to wait to do the required changes. Heh, now that I look more carefully... it IS documented, line 38 of contributing/versioning.rst: > ABI versions are set at the time of major release labeling, and the > ABI may change multiple times, without warning, between the last > release label and the HEAD label of the git tree. >> The "problem" is that during a development cycle, an ABI could be broken >> several times but LIBABIVER should only be bumped once. So ABI breaking >> commits will often not be atomic wrt LIBABIVER, no matter which way its >> done. > > If the ABI version has already been changed, there should be a merge conflict. > I think it's better to manage a conflict than forget to update the version. What I'm thinking of is something that would tie LIBABIVER to the deprecation announcement in a way that could be easily checked (programmatically and manually). As it is now, its quite non-trivial to figure what LIBABIVER *should* be for a given library at a given point - you need to dig up deprecation.rst history and Makefile history and whatnot, and its all quite error-prone. >> For example libtool recommendation is that library versions are updated >> only just before public releases: >> https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info > > Interesting link. It makes me think that we do not manage ABI break when > downgrading the library (case of only new API keeping the ABI number). Hmm, not quite sure what you mean here, but full libtool-style versioning is not really needed with symbol versioning. - Panu - > >>> In this case, I've missed it when reviewing the vhost patches breaking the >>> ABI. >
[dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 18:48, Panu Matilainen: > On 12/07/2015 03:55 PM, Thomas Monjalon wrote: > > 2015-12-07 13:41, Panu Matilainen: > >> On 12/07/2015 01:28 PM, Thomas Monjalon wrote: > >>> 2015-12-07 08:29, Panu Matilainen: > On 12/07/2015 01:07 AM, Thomas Monjalon wrote: > > 2015-12-02 15:53, Panu Matilainen: > The vhost ABI break was announced for DPDK 2.2 in commit > 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d: > >>> [...] > So the ABI process was properly followed, except for actually bumping > LIBABIVER. Bumping LIBABIVER is mentioned in > doc/guides/contributing/versioning.rst but it doesn't specify *when* > this should be done, eg should the first patch breaking the ABI bump it > or should it done be shortly before the next stable release, or > something else. As it is, it seems a bit too easy to simply forget. > >>> > >>> I thought it was not needed to explicitly say that commits must be atomic > >>> and we do not have to wait to do the required changes. > > Heh, now that I look more carefully... it IS documented, line 38 of > contributing/versioning.rst: > > > ABI versions are set at the time of major release labeling, and the > > ABI may change multiple times, without warning, between the last > > release label and the HEAD label of the git tree. Interesting :) > >> The "problem" is that during a development cycle, an ABI could be broken > >> several times but LIBABIVER should only be bumped once. So ABI breaking > >> commits will often not be atomic wrt LIBABIVER, no matter which way its > >> done. > > > > If the ABI version has already been changed, there should be a merge > > conflict. > > I think it's better to manage a conflict than forget to update the version. > > What I'm thinking of is something that would tie LIBABIVER to the > deprecation announcement in a way that could be easily checked > (programmatically and manually). As it is now, its quite non-trivial to > figure what LIBABIVER *should* be for a given library at a given point - > you need to dig up deprecation.rst history and Makefile history and > whatnot, and its all quite error-prone. Yes clearly we need a safer process. You are welcome to suggest one. I like the idea of being based on some "parse-able" RST changes.
[dpdk-dev] [PATCH v2 2/2] eal/linux: Add support for handling built-in kernel modules
Hello Kamil,
On Mon, Dec 7, 2015 at 5:57 PM, Kamil Rytarowski <
Kamil.Rytarowski at caviumnetworks.com> wrote:
> Currently rte_eal_check_module() detects Linux kernel modules via reading
> /proc/modules. Built-in ones aren't listed there and therefore they are not
> being found by the script.
>
> Add support for checking built-in modules with parsing the sysfs files
>
> Signed-off-by: Kamil Rytarowski
> ---
> lib/librte_eal/linuxapp/eal/eal.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal.c
> b/lib/librte_eal/linuxapp/eal/eal.c
> index 635ec36..6cab906 100644
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -52,6 +52,8 @@
> #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
> #include
> #endif
> +#include
> +#include
>
> #include
> #include
> @@ -902,7 +904,10 @@ int
> rte_eal_check_module(const char *module_name)
> {
> char mod_name[30]; /* Any module names can be longer than 30
> bytes? */
> + char sysfs_mod_name[PATH_MAX];
> + struct stat st;
> int ret = 0;
> + int rv;
> int n;
>
> if (NULL == module_name)
> @@ -918,9 +923,23 @@ rte_eal_check_module(const char *module_name)
> n = fscanf(fd, "%29s %*[^\n]", mod_name);
> if ((n == 1) && !strcmp(mod_name, module_name)) {
> ret = 1;
> - break;
> + goto finish;
> }
> }
> + RTE_LOG(DEBUG, EAL, "Module %s not found in /proc/modules",
> + module_name);
> +
> + /* A module might be builtin, try sysfs */
> + snprintf(sysfs_mod_name, PATH_MAX, "/sys/module/%s", module_name);
> + if ((rv = stat(sysfs_mod_name, )) == 0) {
> + ret = 1;
> + goto finish;
> + }
> +
> + RTE_LOG(DEBUG, EAL, "Open %s failed! error %i (%s)\n",
> + sysfs_mod_name, errno, strerror(errno));
> +
> +finish:
> fclose(fd);
>
> return ret;
>
Well, in the end, won't all modules end up in /sys/module ?
So, I would say we can get rid of /proc/modules parsing.
The only thing that bothers me is this comment in the kernel documentation :
/sys/module/MODULENAME
The name of the module that is in the kernel.
This
module name will always show up if the module is loaded as
a
dynamic module. If it is built directly into the kernel,
it
will only show up if it has a version or at least
one
parameter.
Note: The conditions of creation in the built-in case are
not
by design and may be removed in the
future.
But, at the moment, I suppose we are fine.
--
David Marchand
[dpdk-dev] [PATCH v2] scripts: support any legal git revisions as abi validation range
On 12/07/2015 04:32 PM, Thomas Monjalon wrote: > 2015-12-07 16:09, Panu Matilainen: >> On 12/03/2015 04:05 PM, Panu Matilainen wrote: >>> In addition to git tags, support validating abi between any legal >>> gitrevisions(7) syntaxes, such as "validate-abi.sh -1 . " >>> "validate-abi.sh master mybranch " etc in addition to >>> validating between tags. Makes it easier to run the validator >>> for in-development work. >>> >>> Signed-off-by: Panu Matilainen >>> Acked-by: Neil Horman >>> --- >>> >>> v2 changes: >>> - update usage and error messages to match new behavior >>> - update documentation too (as suggested by John McNamara) >>> >> >> I started wondering why this didn't get applied along with the other >> abi-validator changes and noticed this is sitting in patchwork in >> "changes requested" state, which doesn't seem right: v2 added the >> requested documentation. > > It seems to be an error. > >> The discussion around this patch did spur another request (ability to >> pass parallel build flags to make) but that's entirely unrelated, so it >> shouldn't hold up this one. > > Yes > >> I've no intention of sending a v3 of this patch because AFAIK there's >> nothing to fix and the make-flags thing does not belong here, but >> resetting the state to "new" by myself feels like cheating or something >> :) So what's the correct action here? There's preciously little >> documentation about expected patchwork workflow and such. > > It's not cheating. > Changing patchwork status and send such an email looks to be the right thing > to do. Ok, done. Thanks for clarifying. > > Yes maybe we can improve the contributing guide. Perhaps this could be used as a base, or referred to (assuming of course the info is rasonably applicaple to dpdk too)? https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow - Panu - > Thanks >
[dpdk-dev] [PATCH v9 4/4] examples: add pthread_shim example to performance thread
This commit adds an example that illustrates how to implement a pthread shim with the lthread subsystem included in the performance thread example application. Signed-off-by: Ian Betts --- examples/performance-thread/Makefile | 2 + examples/performance-thread/pthread_shim/Makefile | 60 ++ examples/performance-thread/pthread_shim/main.c| 284 .../performance-thread/pthread_shim/pthread_shim.c | 714 + .../performance-thread/pthread_shim/pthread_shim.h | 113 5 files changed, 1173 insertions(+) create mode 100644 examples/performance-thread/pthread_shim/Makefile create mode 100644 examples/performance-thread/pthread_shim/main.c create mode 100644 examples/performance-thread/pthread_shim/pthread_shim.c create mode 100644 examples/performance-thread/pthread_shim/pthread_shim.h diff --git a/examples/performance-thread/Makefile b/examples/performance-thread/Makefile index 0a02e90..75389d7 100644 --- a/examples/performance-thread/Makefile +++ b/examples/performance-thread/Makefile @@ -39,5 +39,7 @@ RTE_TARGET ?= x86_64-native-linuxapp-gcc include $(RTE_SDK)/mk/rte.vars.mk DIRS-y += l3fwd-thread +DIRS-y += pthread_shim + include $(RTE_SDK)/mk/rte.extsubdir.mk diff --git a/examples/performance-thread/pthread_shim/Makefile b/examples/performance-thread/pthread_shim/Makefile new file mode 100644 index 000..9cf32e3 --- /dev/null +++ b/examples/performance-thread/pthread_shim/Makefile @@ -0,0 +1,60 @@ +# BSD LICENSE +# +# Copyright(c) 2015 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +ifeq ($(RTE_SDK),) +$(error "Please define RTE_SDK environment variable") +endif + +# Default target, can be overridden by command line or environment +RTE_TARGET ?= x86_64-native-linuxapp-gcc + +include $(RTE_SDK)/mk/rte.vars.mk + +# binary name +APP = lthread_pthread_shim + +# all source are stored in SRCS-y +SRCS-y := main.c pthread_shim.c +INCLUDES := -I$(RTE_SDK)/$(RTE_TARGET)/include -I$(SRCDIR) +include $(RTE_SDK)/examples/performance-thread/common/common.mk + +CFLAGS=-g -O3 $(USER_FLAGS) $(INCLUDES) +CFLAGS += $(WERROR_FLAGS) + +LDFLAGS += -lpthread + +# workaround for a gcc bug with noreturn attribute +# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 +ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) +CFLAGS_main.o += -Wno-return-type +endif + +include $(RTE_SDK)/mk/rte.extapp.mk diff --git a/examples/performance-thread/pthread_shim/main.c b/examples/performance-thread/pthread_shim/main.c new file mode 100644 index 000..2f67c1b --- /dev/null +++ b/examples/performance-thread/pthread_shim/main.c @@ -0,0 +1,284 @@ + +/*- + * BSD LICENSE + * + * Copyright(c) 2015 Intel Corporation. All rights reserved. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of Intel Corporation nor the names of its + * contributors may be used to
[dpdk-dev] [PATCH v9 3/4] examples: add l3fwd-thread example in performance-thread
This commit adds an L3 forwarding application to the performace-thread example. Signed-off-by: Ian Betts --- MAINTAINERS |7 + examples/Makefile |6 +- examples/performance-thread/Makefile | 43 + examples/performance-thread/l3fwd-thread/Makefile | 57 + examples/performance-thread/l3fwd-thread/main.c | 3641 + examples/performance-thread/l3fwd-thread/test.sh | 149 + 6 files changed, 3902 insertions(+), 1 deletion(-) create mode 100644 examples/performance-thread/Makefile create mode 100644 examples/performance-thread/l3fwd-thread/Makefile create mode 100644 examples/performance-thread/l3fwd-thread/main.c create mode 100755 examples/performance-thread/l3fwd-thread/test.sh diff --git a/MAINTAINERS b/MAINTAINERS index 8319ce1..b3b95a0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -575,3 +575,10 @@ F: doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst M: Pablo de Lara M: Daniel Mrzyglod F: examples/ptpclient/ + +M: Ian Betts +F: examples/performance-thread/ + +M: Ian Betts +M: John McNamara +F: doc/guides/sample_app_ug/performance_thread.rst diff --git a/examples/Makefile b/examples/Makefile index 5dd2c53..11793e3 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -77,5 +77,9 @@ DIRS-y += vmdq DIRS-y += vmdq_dcb DIRS-$(CONFIG_RTE_LIBRTE_POWER) += vm_power_manager DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += l2fwd-crypto - +ifneq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),) +ifneq ($(CONFIG_RTE_ARCH_X86_64),) +DIRS-y += performance-thread +endif +endif include $(RTE_SDK)/mk/rte.extsubdir.mk diff --git a/examples/performance-thread/Makefile b/examples/performance-thread/Makefile new file mode 100644 index 000..0a02e90 --- /dev/null +++ b/examples/performance-thread/Makefile @@ -0,0 +1,43 @@ +# BSD LICENSE +# +# Copyright(c) 2015 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +ifeq ($(RTE_SDK),) +$(error "Please define RTE_SDK environment variable") +endif + +# Default target, can be overridden by command line or environment +RTE_TARGET ?= x86_64-native-linuxapp-gcc + +include $(RTE_SDK)/mk/rte.vars.mk + +DIRS-y += l3fwd-thread + +include $(RTE_SDK)/mk/rte.extsubdir.mk diff --git a/examples/performance-thread/l3fwd-thread/Makefile b/examples/performance-thread/l3fwd-thread/Makefile new file mode 100644 index 000..d8fe5e6 --- /dev/null +++ b/examples/performance-thread/l3fwd-thread/Makefile @@ -0,0 +1,57 @@ +# BSD LICENSE +# +# Copyright(c) 2010-2015 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE
[dpdk-dev] [PATCH v9 2/4] examples: add lthread subsystem for performance-thread
This commit adds the lightweight thread subsystem used by the performance-thread sample applications. Signed-off-by: Ian Betts --- examples/performance-thread/common/arch/x86/ctx.c | 93 +++ examples/performance-thread/common/arch/x86/ctx.h | 57 ++ examples/performance-thread/common/common.mk | 42 ++ examples/performance-thread/common/lthread.c | 530 + examples/performance-thread/common/lthread.h | 99 +++ examples/performance-thread/common/lthread_api.h | 829 + examples/performance-thread/common/lthread_cond.c | 240 ++ examples/performance-thread/common/lthread_cond.h | 77 ++ examples/performance-thread/common/lthread_diag.c | 321 examples/performance-thread/common/lthread_diag.h | 129 .../performance-thread/common/lthread_diag_api.h | 319 examples/performance-thread/common/lthread_int.h | 212 ++ examples/performance-thread/common/lthread_mutex.c | 255 +++ examples/performance-thread/common/lthread_mutex.h | 52 ++ .../performance-thread/common/lthread_objcache.h | 160 examples/performance-thread/common/lthread_pool.h | 332 + examples/performance-thread/common/lthread_queue.h | 302 examples/performance-thread/common/lthread_sched.c | 600 +++ examples/performance-thread/common/lthread_sched.h | 152 examples/performance-thread/common/lthread_timer.h | 79 ++ examples/performance-thread/common/lthread_tls.c | 254 +++ examples/performance-thread/common/lthread_tls.h | 57 ++ 22 files changed, 5191 insertions(+) create mode 100644 examples/performance-thread/common/arch/x86/ctx.c create mode 100644 examples/performance-thread/common/arch/x86/ctx.h create mode 100644 examples/performance-thread/common/common.mk create mode 100644 examples/performance-thread/common/lthread.c create mode 100644 examples/performance-thread/common/lthread.h create mode 100644 examples/performance-thread/common/lthread_api.h create mode 100644 examples/performance-thread/common/lthread_cond.c create mode 100644 examples/performance-thread/common/lthread_cond.h create mode 100644 examples/performance-thread/common/lthread_diag.c create mode 100644 examples/performance-thread/common/lthread_diag.h create mode 100644 examples/performance-thread/common/lthread_diag_api.h create mode 100644 examples/performance-thread/common/lthread_int.h create mode 100644 examples/performance-thread/common/lthread_mutex.c create mode 100644 examples/performance-thread/common/lthread_mutex.h create mode 100644 examples/performance-thread/common/lthread_objcache.h create mode 100644 examples/performance-thread/common/lthread_pool.h create mode 100644 examples/performance-thread/common/lthread_queue.h create mode 100644 examples/performance-thread/common/lthread_sched.c create mode 100644 examples/performance-thread/common/lthread_sched.h create mode 100644 examples/performance-thread/common/lthread_timer.h create mode 100644 examples/performance-thread/common/lthread_tls.c create mode 100644 examples/performance-thread/common/lthread_tls.h diff --git a/examples/performance-thread/common/arch/x86/ctx.c b/examples/performance-thread/common/arch/x86/ctx.c new file mode 100644 index 000..1e8e271 --- /dev/null +++ b/examples/performance-thread/common/arch/x86/ctx.c @@ -0,0 +1,93 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2015 Intel Corporation. All rights reserved. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of Intel Corporation nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE)
[dpdk-dev] [PATCH v9 1/4] doc: add sample application guide for performance-thread
This commit adds the sample application user guide for the performance thread sample application. Signed-off-by: Ian Betts --- .../sample_app_ug/img/performance_thread_1.svg | 799 + .../sample_app_ug/img/performance_thread_2.svg | 865 ++ doc/guides/sample_app_ug/index.rst |1 + doc/guides/sample_app_ug/performance_thread.rst| 1263 4 files changed, 2928 insertions(+) create mode 100644 doc/guides/sample_app_ug/img/performance_thread_1.svg create mode 100644 doc/guides/sample_app_ug/img/performance_thread_2.svg create mode 100644 doc/guides/sample_app_ug/performance_thread.rst diff --git a/doc/guides/sample_app_ug/img/performance_thread_1.svg b/doc/guides/sample_app_ug/img/performance_thread_1.svg new file mode 100644 index 000..db01d7c --- /dev/null +++ b/doc/guides/sample_app_ug/img/performance_thread_1.svg @@ -0,0 +1,799 @@ + + + +http://purl.org/dc/elements/1.1/; + xmlns:cc="http://creativecommons.org/ns#; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#; + xmlns:svg="http://www.w3.org/2000/svg; + xmlns="http://www.w3.org/2000/svg; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape; + width="449.57141" + height="187.34319" + viewBox="0 0 449.57143 187.34319" + id="svg2" + version="1.1" + inkscape:version="0.48.3.1 r9886" + sodipodi:docname="performance_thread_1.svg" + inkscape:export-filename="C:\Users\tkulasex\Documents\L-threads\model-v2.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage; /> + + + + + + + + + + Port 1 + + +Port 2 + + + rx-thread + +rings + + + + + + rx-thread + + + + Port 1 + + +Port 2 + + + tx-thread + + + + + + tx-thread + + + + + + + tx-thread + + + + + + + + diff --git a/doc/guides/sample_app_ug/img/performance_thread_2.svg b/doc/guides/sample_app_ug/img/performance_thread_2.svg new file mode 100644 index 000..48cf833 --- /dev/null +++ b/doc/guides/sample_app_ug/img/performance_thread_2.svg @@ -0,0 +1,865 @@ + + + +http://purl.org/dc/elements/1.1/; + xmlns:cc="http://creativecommons.org/ns#; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#; + xmlns:svg="http://www.w3.org/2000/svg; + xmlns="http://www.w3.org/2000/svg; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape; + width="449.57141" + height="187.34319" + viewBox="0 0 449.57143 187.34319" + id="svg2" + version="1.1" + inkscape:version="0.48.3.1 r9886" + sodipodi:docname="performance_thread_2.svg" + inkscape:export-filename="C:\Users\tkulasex\Documents\L-threads\model-v2.png" + inkscape:export-xdpi="90" + inkscape:export-ydpi="90"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +image/svg+xml +http://purl.org/dc/dcmitype/StillImage; /> + + + + + + + + + + Port 1 + + +Port 2 + + + rx-thread + +rings + + + + + + rx-thread + + + + Port 1 + + +Port 2 + +
[dpdk-dev] [PATCH v9 0/4] examples: add performance-thread
This patchset comprises a layer 3 forwarding derivative intended to facilitate characterization of performance with different threading models, specifically:- 1. EAL threads running on different physical cores 2. EAL threads running on the same physical core 3. Lightweight threads running in an EAL thread Purpose and justification Since dpdk 2.0 it has been possible to assign multiple EAL threads to a physical core ( case 2 above ). Currently no example application has focused on demonstrating the performance constraints of differing threading models. Whilst purpose built applications that fully comprehend the DPDK single threaded programming model will always yield superior performance, the desire to preserve ROI in legacy code written for multithreaded operating environments makes lightweight threads (case 3 above) worthy of consideration. As well as aiding with legacy code reuse, it is anticipated that lightweight threads will make it possible to scale a multithreaded application with fine granularity allowing an application to more easily take advantage of headroom on EAL cores, or conversely occupy more cores, as dictated by system load. To explore performance with lightweight threads a simple cooperative scheduler subsystem is being included in this example application. If the expected benefits and use cases prove to be of value, it is anticipated that this lightweight thread subsystem would become a library in some future DPDK release. Changes in this version * Remove CONFIG_RTE_PERFORMANCE_THREAD Ian Betts (4): doc: add sample application guide for performance-thread examples: add lthread subsystem for performance-thread examples: add l3fwd-thread example in performance-thread examples: add pthread_shim example to performance thread MAINTAINERS|7 + .../sample_app_ug/img/performance_thread_1.svg | 799 + .../sample_app_ug/img/performance_thread_2.svg | 865 + doc/guides/sample_app_ug/index.rst |1 + doc/guides/sample_app_ug/performance_thread.rst| 1263 +++ examples/Makefile |6 +- examples/performance-thread/Makefile | 45 + examples/performance-thread/common/arch/x86/ctx.c | 93 + examples/performance-thread/common/arch/x86/ctx.h | 57 + examples/performance-thread/common/common.mk | 42 + examples/performance-thread/common/lthread.c | 530 +++ examples/performance-thread/common/lthread.h | 99 + examples/performance-thread/common/lthread_api.h | 829 + examples/performance-thread/common/lthread_cond.c | 240 ++ examples/performance-thread/common/lthread_cond.h | 77 + examples/performance-thread/common/lthread_diag.c | 321 ++ examples/performance-thread/common/lthread_diag.h | 129 + .../performance-thread/common/lthread_diag_api.h | 319 ++ examples/performance-thread/common/lthread_int.h | 212 ++ examples/performance-thread/common/lthread_mutex.c | 255 ++ examples/performance-thread/common/lthread_mutex.h | 52 + .../performance-thread/common/lthread_objcache.h | 160 + examples/performance-thread/common/lthread_pool.h | 332 ++ examples/performance-thread/common/lthread_queue.h | 302 ++ examples/performance-thread/common/lthread_sched.c | 600 examples/performance-thread/common/lthread_sched.h | 152 + examples/performance-thread/common/lthread_timer.h | 79 + examples/performance-thread/common/lthread_tls.c | 254 ++ examples/performance-thread/common/lthread_tls.h | 57 + examples/performance-thread/l3fwd-thread/Makefile | 57 + examples/performance-thread/l3fwd-thread/main.c| 3641 examples/performance-thread/l3fwd-thread/test.sh | 149 + examples/performance-thread/pthread_shim/Makefile | 60 + examples/performance-thread/pthread_shim/main.c| 284 ++ .../performance-thread/pthread_shim/pthread_shim.c | 714 .../performance-thread/pthread_shim/pthread_shim.h | 113 + 36 files changed, 13194 insertions(+), 1 deletion(-) create mode 100644 doc/guides/sample_app_ug/img/performance_thread_1.svg create mode 100644 doc/guides/sample_app_ug/img/performance_thread_2.svg create mode 100644 doc/guides/sample_app_ug/performance_thread.rst create mode 100644 examples/performance-thread/Makefile create mode 100644 examples/performance-thread/common/arch/x86/ctx.c create mode 100644 examples/performance-thread/common/arch/x86/ctx.h create mode 100644 examples/performance-thread/common/common.mk create mode 100644 examples/performance-thread/common/lthread.c create mode 100644 examples/performance-thread/common/lthread.h create mode 100644 examples/performance-thread/common/lthread_api.h create mode 100644 examples/performance-thread/common/lthread_cond.c create mode 100644 examples/performance-thread/common/lthread_cond.h create mode 100644 examples/performance-thread/common/lthread_diag.c create mode
[dpdk-dev] [PATCH v2 2/2] eal/linux: Add support for handling built-in kernel modules
Currently rte_eal_check_module() detects Linux kernel modules via reading
/proc/modules. Built-in ones aren't listed there and therefore they are not
being found by the script.
Add support for checking built-in modules with parsing the sysfs files
Signed-off-by: Kamil Rytarowski
---
lib/librte_eal/linuxapp/eal/eal.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 635ec36..6cab906 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -52,6 +52,8 @@
#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
#include
#endif
+#include
+#include
#include
#include
@@ -902,7 +904,10 @@ int
rte_eal_check_module(const char *module_name)
{
char mod_name[30]; /* Any module names can be longer than 30 bytes? */
+ char sysfs_mod_name[PATH_MAX];
+ struct stat st;
int ret = 0;
+ int rv;
int n;
if (NULL == module_name)
@@ -918,9 +923,23 @@ rte_eal_check_module(const char *module_name)
n = fscanf(fd, "%29s %*[^\n]", mod_name);
if ((n == 1) && !strcmp(mod_name, module_name)) {
ret = 1;
- break;
+ goto finish;
}
}
+ RTE_LOG(DEBUG, EAL, "Module %s not found in /proc/modules",
+ module_name);
+
+ /* A module might be builtin, try sysfs */
+ snprintf(sysfs_mod_name, PATH_MAX, "/sys/module/%s", module_name);
+ if ((rv = stat(sysfs_mod_name, )) == 0) {
+ ret = 1;
+ goto finish;
+ }
+
+ RTE_LOG(DEBUG, EAL, "Open %s failed! error %i (%s)\n",
+ sysfs_mod_name, errno, strerror(errno));
+
+finish:
fclose(fd);
return ret;
--
2.5.0
[dpdk-dev] [PATCH v2 1/2] tools: Add support for handling built-in kernel modules
Currently dpdk_nic_bind.py detects Linux kernel modules via reading
/proc/modules. Built-in ones aren't listed there and therefore they are not
being found by the script.
Add support for checking built-in modules with parsing the sysfs files.
Signed-off-by: Kamil Rytarowski
---
tools/dpdk_nic_bind.py | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/tools/dpdk_nic_bind.py b/tools/dpdk_nic_bind.py
index f02454e..cb1ac80 100755
--- a/tools/dpdk_nic_bind.py
+++ b/tools/dpdk_nic_bind.py
@@ -33,7 +33,7 @@
#
import sys, os, getopt, subprocess
-from os.path import exists, abspath, dirname, basename
+from os.path import exists, abspath, dirname, basename, join
# The PCI device class for ETHERNET devices
@@ -173,6 +173,26 @@ def check_modules():
elif line.replace("_", "-").startswith(mod["Name"]):
mod["Found"] = True
+try:
+# Get list of syfs modules, some of them might be builtin and merge
with mods
+sysfs_path = '/sys/module/'
+
+# Get the list of directories in sysfs_path
+sysfs_mods = [os.path.join(sysfs_path,o) for o in
os.listdir(sysfs_path) if os.path.isdir(os.path.join(sysfs_path,o))]
+
+# Extract the last element of '/sys/module/abc' in the array
+sysfs_mods = [a.split('/')[-1] for a in sysfs_mods]
+
+# special case for vfio_pci (module is named vfio-pci,
+# but its .ko is named vfio_pci)
+sysfs_mods = map(lambda a: a if a != 'vfio_pci' else 'vfio-pci',
sysfs_mods)
+
+for mod in mods:
+if mod["Found"] == False and (mod["Name"] in sysfs_mods):
+mod["Found"] = True
+except:
+pass
+
# check if we have at least one loaded module
if True not in [mod["Found"] for mod in mods] and b_flag is not None:
if b_flag in dpdk_drivers:
--
2.5.0
[dpdk-dev] KNI sample application running procedure
Hi Nishant, Thanks for your suggestions but even it did not work, In the meanwhile, I will see what can I do from my side. Any other suggestions from the community is also really helpful at this time root at x10sdv-f:/opt/dpdk/x86_64-native-linuxapp-gcc/app# ./kni -c 0x0f -n 2 -- -P -p 0x3 --config="(0,2,3),(1,0,1)" EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 1 on socket 0 EAL: Detected lcore 2 as core 2 on socket 0 EAL: Detected lcore 3 as core 3 on socket 0 EAL: Detected lcore 4 as core 4 on socket 0 EAL: Detected lcore 5 as core 5 on socket 0 EAL: Detected lcore 6 as core 6 on socket 0 EAL: Detected lcore 7 as core 7 on socket 0 EAL: Detected lcore 8 as core 0 on socket 0 EAL: Detected lcore 9 as core 1 on socket 0 EAL: Detected lcore 10 as core 2 on socket 0 EAL: Detected lcore 11 as core 3 on socket 0 EAL: Detected lcore 12 as core 4 on socket 0 EAL: Detected lcore 13 as core 5 on socket 0 EAL: Detected lcore 14 as core 6 on socket 0 EAL: Detected lcore 15 as core 7 on socket 0 EAL: Support maximum 16 logical core(s) by configuration. EAL: Detected 16 lcore(s) EAL: VFIO modules not all loaded, skip VFIO support... EAL: Setting up physically contiguous memory... EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7ff6be40 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7ff6be00 (size = 0x20) EAL: Ask a virtual area of 0x3c40 bytes EAL: Virtual area found at 0x7ff681a0 (size = 0x3c40) EAL: Ask a virtual area of 0x360 bytes EAL: Virtual area found at 0x7ff67e20 (size = 0x360) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7ff67de0 (size = 0x20) EAL: Ask a virtual area of 0xc000 bytes EAL: Virtual area found at 0x7ff5bdc0 (size = 0xc000) EAL: Requesting 2048 pages of size 2MB from socket 0 EAL: TSC frequency is ~201 KHz EAL: Master lcore 0 is ready (tid=bf8028c0;cpuset=[0]) EAL: lcore 3 is ready (tid=bcbfd700;cpuset=[3]) EAL: lcore 1 is ready (tid=bdbff700;cpuset=[1]) EAL: lcore 2 is ready (tid=bd3fe700;cpuset=[2]) EAL: PCI device :03:00.0 on NUMA socket -1 EAL: probe driver: 8086:15ad rte_ixgbe_pmd EAL: Not managed by a supported kernel driver, skipped EAL: PCI device :03:00.1 on NUMA socket -1 EAL: probe driver: 8086:15ad rte_ixgbe_pmd EAL: Not managed by a supported kernel driver, skipped EAL: PCI device :05:00.0 on NUMA socket -1 EAL: probe driver: 8086:1521 rte_igb_pmd EAL: PCI memory mapped at 0x7ff6be60 EAL: PCI memory mapped at 0x7ff6be62 PMD: eth_igb_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x1521 EAL: PCI device :05:00.1 on NUMA socket -1 EAL: probe driver: 8086:1521 rte_igb_pmd EAL: PCI memory mapped at 0x7ff6be624000 EAL: PCI memory mapped at 0x7ff6be644000 PMD: eth_igb_dev_init(): port_id 1 vendorID=0x8086 deviceID=0x1521 APP: Port ID: 0 APP: Rx lcore ID: 2, Tx lcore ID: 3 APP: Port ID: 1 APP: Rx lcore ID: 0, Tx lcore ID: 1 EAL: Error - exiting with code: 1 Cause: portmask is not consistent to port ids specified in --config root at x10sdv-f:/opt/dpdk/x86_64-native-linuxapp-gcc/app# Thanks Jaffar From: Nishant Verma [mailto:vnis...@gmail.com] Sent: Monday, December 07, 2015 1:58 PM To: Abdul, Jaffar Cc: dev at dpdk.org; Ismail, Aws Subject: Re: [dpdk-dev] KNI sample application running procedure As par error message, it seems error lies in validation. But it seems right Can you try to run the app without kthread option. if you haven't tried that. just to pin point the problem. ./kni -c 0x0f -n 2 -- -P -p 0x3 --config="(0,2,3),(1,0,1)" while executing, load kni module with single mode option. On Mon, Dec 7, 2015 at 3:48 PM, Abdul, Jaffar mailto:jabdul at ciena.com>> wrote: Hi Guys, I am trying to run the KNI sample application according to the DPDK documentation which is given below. http://dpdk.org/doc/guides/sample_app_ug/kernel_nic_interface.html#running-the-application I am not able to run the app successfully, I don't have this problem with any other DPDK example application and I also verified that I have loaded the *.ko files properly (rte_kni.ko, igb_uio.ko, etc.) I have also loaded rte_kni.ko with kthread_mode single/multiple but both results are same. I am using two 1G ports in this example which are port 0 and port 1 and it has been attached to DPDK through (dpdk_nic_bind.py) script. Output of the dpdk_nic_bind.py root at x10sdv-f:/# /opt/dpdk/tools/dpdk_nic_bind.py --status Network devices using DPDK-compatible driver :05:00.0 'I350 Gigabit Network Connection' drv=igb_uio unused= :05:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused= Network devices using kernel driver === :03:00.0 'Device 15ad' if=eth2 drv=ixgbe unused=igb_uio :03:00.1 'Device 15ad' if=eth3 drv=ixgbe unused=igb_uio Other network devices
[dpdk-dev] [PATCH v9 3/4] examples: add l3fwd-thread example in performance-thread
2015-12-07 17:58, Ian Betts: > examples/performance-thread/l3fwd-thread/main.c | 3641 + It does not compile with clang: common/lthread_diag.c:165:1: error: unused function '_qnode_pool_display'
[dpdk-dev] [PATCH] bnx2x: set Ethernet address type during transmit for VF's
>
>On Sun, 2015-12-06 at 23:34 +, Harish Patil wrote:
>> >
>> >The original was always setting unicast. While here, clean up some
>> >other references that also point into the Ethernet header.
>> >
>> >Signed-off-by: Chas Williams <3chas3 at gmail.com>
>> >---
>> > drivers/net/bnx2x/bnx2x.c | 23 +++
>> > drivers/net/bnx2x/ecore_hsi.h | 5 +++--
>> > 2 files changed, 18 insertions(+), 10 deletions(-)
>> >
>> >diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
>> >index 76444eb..294711f 100644
>> >--- a/drivers/net/bnx2x/bnx2x.c
>> >+++ b/drivers/net/bnx2x/bnx2x.c
>> >@@ -2177,25 +2177,32 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq,
>> >struct rte_mbuf **m_head, int m_p
>> > bd_prod = NEXT_TX_BD(bd_prod);
>> > if (IS_VF(sc)) {
>> > struct eth_tx_parse_bd_e2 *tx_parse_bd;
>> >- uint8_t *data = rte_pktmbuf_mtod(m0, uint8_t *);
>> >+ const struct ether_hdr *eh =
>>rte_pktmbuf_mtod(m0, struct ether_hdr *);
>> >+ uint8_t mac_type = UNICAST_ADDRESS;
>> >
>> > tx_parse_bd =
>> > >tx_ring[TX_BD(bd_prod,
>>txq)].parse_bd_e2;
>> >+ if (is_multicast_ether_addr(>d_addr)) {
>>
>> Minor comment. unlikely() may be used here to keep it consistent with
>>base
>> driver.
>
>It wasn't clear to me that this code path is all that unlikely().
Its an optional comment, unlikely() is because fast path traffic is mostly
unicast.
BTW, have you tested the patches? Another question, not related to your
change though.
I guess this block of code does not have to been under the IS_VF() check.
>
>> >+ if
>>(is_broadcast_ether_addr(>d_addr))
>> >+ mac_type = BROADCAST_ADDRESS;
>> >+ else
>> >+ mac_type = MULTICAST_ADDRESS;
>> >+ }
>
>
>
This message and any attached documents contain information from the sending
company or its parent company(s), subsidiaries, divisions or branch offices
that may be confidential. If you are not the intended recipient, you may not
read, copy, distribute, or use this information. If you have received this
transmission in error, please notify the sender immediately by reply e-mail and
then delete this message.
[dpdk-dev] KNI sample application running procedure
As par error message, it seems error lies in validation. But it seems right Can you try to run the app without kthread option. if you haven't tried that. just to pin point the problem. ./kni -c 0x0f -n 2 -- -P -p 0x3 --config="(0,2,3),(1,0,1)" while executing, load kni module with single mode option. On Mon, Dec 7, 2015 at 3:48 PM, Abdul, Jaffar wrote: > Hi Guys, > > I am trying to run the KNI sample application according to the DPDK > documentation which is given below. > > > http://dpdk.org/doc/guides/sample_app_ug/kernel_nic_interface.html#running-the-application > > I am not able to run the app successfully, > > I don't have this problem with any other DPDK example application and I > also verified that I have loaded the *.ko files properly (rte_kni.ko, > igb_uio.ko, etc.) > > I have also loaded rte_kni.ko with kthread_mode single/multiple but both > results are same. > > I am using two 1G ports in this example which are port 0 and port 1 and it > has been attached to DPDK through (dpdk_nic_bind.py) script. > > Output of the dpdk_nic_bind.py > > root at x10sdv-f:/# /opt/dpdk/tools/dpdk_nic_bind.py --status > > Network devices using DPDK-compatible driver > > :05:00.0 'I350 Gigabit Network Connection' drv=igb_uio unused= > :05:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused= > > Network devices using kernel driver > === > :03:00.0 'Device 15ad' if=eth2 drv=ixgbe unused=igb_uio > :03:00.1 'Device 15ad' if=eth3 drv=ixgbe unused=igb_uio > > Other network devices > = > > > Here is how I am loading the KNI sample application > > root at x10sdv-f:/opt/dpdk/x86_64-native-linuxapp-gcc/app# ./kni -c 0x0f -n > 2 -- -P -p 0x3 --config="(0,2,3,0),(1,0,1,0)" > EAL: Detected lcore 0 as core 0 on socket 0 > EAL: Detected lcore 1 as core 1 on socket 0 > EAL: Detected lcore 2 as core 2 on socket 0 > EAL: Detected lcore 3 as core 3 on socket 0 > EAL: Detected lcore 4 as core 4 on socket 0 > EAL: Detected lcore 5 as core 5 on socket 0 > EAL: Detected lcore 6 as core 6 on socket 0 > EAL: Detected lcore 7 as core 7 on socket 0 > EAL: Detected lcore 8 as core 0 on socket 0 > EAL: Detected lcore 9 as core 1 on socket 0 > EAL: Detected lcore 10 as core 2 on socket 0 > EAL: Detected lcore 11 as core 3 on socket 0 > EAL: Detected lcore 12 as core 4 on socket 0 > EAL: Detected lcore 13 as core 5 on socket 0 > EAL: Detected lcore 14 as core 6 on socket 0 > EAL: Detected lcore 15 as core 7 on socket 0 > EAL: Support maximum 16 logical core(s) by configuration. > EAL: Detected 16 lcore(s) > EAL: VFIO modules not all loaded, skip VFIO support... > EAL: Setting up physically contiguous memory... > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7fa27460 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7fa27420 (size = 0x20) > EAL: Ask a virtual area of 0x3c40 bytes > EAL: Virtual area found at 0x7fa237c0 (size = 0x3c40) > EAL: Ask a virtual area of 0x360 bytes > EAL: Virtual area found at 0x7fa23440 (size = 0x360) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7fa23400 (size = 0x20) > EAL: Ask a virtual area of 0xc000 bytes > EAL: Virtual area found at 0x7fa173e0 (size = 0xc000) > EAL: Requesting 2048 pages of size 2MB from socket 0 > EAL: TSC frequency is ~201 KHz > EAL: Master lcore 0 is ready (tid=75a328c0;cpuset=[0]) > EAL: lcore 3 is ready (tid=72dfd700;cpuset=[3]) > EAL: lcore 1 is ready (tid=73dff700;cpuset=[1]) > EAL: lcore 2 is ready (tid=735fe700;cpuset=[2]) > EAL: PCI device :03:00.0 on NUMA socket -1 > EAL: probe driver: 8086:15ad rte_ixgbe_pmd > EAL: Not managed by a supported kernel driver, skipped > EAL: PCI device :03:00.1 on NUMA socket -1 > EAL: probe driver: 8086:15ad rte_ixgbe_pmd > EAL: Not managed by a supported kernel driver, skipped > EAL: PCI device :05:00.0 on NUMA socket -1 > EAL: probe driver: 8086:1521 rte_igb_pmd > EAL: PCI memory mapped at 0x7fa27480 > EAL: PCI memory mapped at 0x7fa27482 > PMD: eth_igb_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x1521 > EAL: PCI device :05:00.1 on NUMA socket -1 > EAL: probe driver: 8086:1521 rte_igb_pmd > EAL: PCI memory mapped at 0x7fa274824000 > EAL: PCI memory mapped at 0x7fa274844000 > PMD: eth_igb_dev_init(): port_id 1 vendorID=0x8086 deviceID=0x1521 > APP: Port ID: 0 > APP: Rx lcore ID: 2, Tx lcore ID: 3 > APP: Kernel thread lcore ID: 0 > APP: Port ID: 1 > APP: Rx lcore ID: 0, Tx lcore ID: 1 > APP: Kernel thread lcore ID: 0 > EAL: Error - exiting with code: 1 > Cause: portmask is not consistent to port ids specified in --config > root at x10sdv-f:/opt/dpdk/x86_64-native-linuxapp-gcc/app# > > > > we are using dpdk v2.1 at this moment, any suggestions to make this work
[dpdk-dev] [PATCH] vhost: don't stall if guest is slow
When guest is booting (or any othertime guest is busy) it is possible
for the small receive ring (256) to get full. If this happens the
vhost library should just return normally. It's current behavior
of logging just creates massive log spew/overflow which could even
act as a DoS attack against host.
Reported-by: Nathan Law
Signed-off-by: Stephen Hemminger
---
lib/librte_vhost/vhost_rxtx.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 9322ce6..bbf3fac 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -510,17 +510,12 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t
queue_id,
do {
avail_idx = *((volatile uint16_t
*)>avail->idx);
- if (unlikely(res_cur_idx == avail_idx)) {
- LOG_DEBUG(VHOST_DATA,
- "(%"PRIu64") Failed "
- "to get enough desc from "
- "vring\n",
- dev->device_fh);
+ if (unlikely(res_cur_idx == avail_idx))
goto merge_rx_exit;
- } else {
- update_secure_len(vq, res_cur_idx,
_len, _idx);
- res_cur_idx++;
- }
+
+ update_secure_len(vq, res_cur_idx,
+ _len, _idx);
+ res_cur_idx++;
} while (pkt_len > secure_len);
/* vq->last_used_idx_res is atomically updated. */
--
2.1.4
[dpdk-dev] [PATCH v2] scripts: support any legal git revisions as abi validation range
On 12/03/2015 04:05 PM, Panu Matilainen wrote: > In addition to git tags, support validating abi between any legal > gitrevisions(7) syntaxes, such as "validate-abi.sh -1 . " > "validate-abi.sh master mybranch " etc in addition to > validating between tags. Makes it easier to run the validator > for in-development work. > > Signed-off-by: Panu Matilainen > Acked-by: Neil Horman > --- > > v2 changes: > - update usage and error messages to match new behavior > - update documentation too (as suggested by John McNamara) > I started wondering why this didn't get applied along with the other abi-validator changes and noticed this is sitting in patchwork in "changes requested" state, which doesn't seem right: v2 added the requested documentation. The discussion around this patch did spur another request (ability to pass parallel build flags to make) but that's entirely unrelated, so it shouldn't hold up this one. I've no intention of sending a v3 of this patch because AFAIK there's nothing to fix and the make-flags thing does not belong here, but resetting the state to "new" by myself feels like cheating or something :) So what's the correct action here? There's preciously little documentation about expected patchwork workflow and such. - Panu -
[dpdk-dev] [PATCH] tools: Add support for handling built-in kernel modules
Currently dpdk_nic_bind.py detects Linux kernel modules via reading
/proc/modules. Built-in ones aren't listed there and therefore they are not
being found by the script.
Add support for checking built-in modules with parsing the sysfs files.
Signed-off-by: Kamil Rytarowski
---
tools/dpdk_nic_bind.py | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/tools/dpdk_nic_bind.py b/tools/dpdk_nic_bind.py
index 8523f82..2ddc14a 100755
--- a/tools/dpdk_nic_bind.py
+++ b/tools/dpdk_nic_bind.py
@@ -33,7 +33,7 @@
#
import sys, os, getopt, subprocess
-from os.path import exists, abspath, dirname, basename
+from os.path import exists, abspath, dirname, basename, join
# The PCI device class for ETHERNET devices
@@ -173,6 +173,26 @@ def check_modules():
elif line.replace("_", "-").startswith(mod["Name"]):
mod["Found"] = True
+try:
+# Get list of syfs modules, some of them might be builtin and merge
with mods
+sysfs_path = '/sys/module/'
+
+# Get the list of directories in sysfs_path
+sysfs_mods = [os.path.join(sysfs_path,o) for o in
os.listdir(sysfs_path) if os.path.isdir(os.path.join(sysfs_path,o))]
+
+# Extract the last element of '/sys/module/abc' in the array
+sysfs_mods = [a.split('/')[-1] for a in sysfs_mods]
+
+# special case for vfio_pci (module is named vfio-pci,
+# but its .ko is named vfio_pci)
+sysfs_mods = map(lambda a: a if a != 'vfio_pci' else 'vfio-pci',
sysfs_mods)
+
+for mod in mods:
+if mod["Found"] == False and (mod["Name"] in sysfs_mods):
+mod["Found"] = True
+except:
+pass
+
# check if we have at least one loaded module
if True not in [mod["Found"] for mod in mods] and b_flag is not None:
if b_flag in dpdk_drivers:
--
2.5.0
[dpdk-dev] KNI sample application running procedure
Hi Guys, I am trying to run the KNI sample application according to the DPDK documentation which is given below. http://dpdk.org/doc/guides/sample_app_ug/kernel_nic_interface.html#running-the-application I am not able to run the app successfully, I don't have this problem with any other DPDK example application and I also verified that I have loaded the *.ko files properly (rte_kni.ko, igb_uio.ko, etc.) I have also loaded rte_kni.ko with kthread_mode single/multiple but both results are same. I am using two 1G ports in this example which are port 0 and port 1 and it has been attached to DPDK through (dpdk_nic_bind.py) script. Output of the dpdk_nic_bind.py root at x10sdv-f:/# /opt/dpdk/tools/dpdk_nic_bind.py --status Network devices using DPDK-compatible driver :05:00.0 'I350 Gigabit Network Connection' drv=igb_uio unused= :05:00.1 'I350 Gigabit Network Connection' drv=igb_uio unused= Network devices using kernel driver === :03:00.0 'Device 15ad' if=eth2 drv=ixgbe unused=igb_uio :03:00.1 'Device 15ad' if=eth3 drv=ixgbe unused=igb_uio Other network devices = Here is how I am loading the KNI sample application root at x10sdv-f:/opt/dpdk/x86_64-native-linuxapp-gcc/app# ./kni -c 0x0f -n 2 -- -P -p 0x3 --config="(0,2,3,0),(1,0,1,0)" EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 1 on socket 0 EAL: Detected lcore 2 as core 2 on socket 0 EAL: Detected lcore 3 as core 3 on socket 0 EAL: Detected lcore 4 as core 4 on socket 0 EAL: Detected lcore 5 as core 5 on socket 0 EAL: Detected lcore 6 as core 6 on socket 0 EAL: Detected lcore 7 as core 7 on socket 0 EAL: Detected lcore 8 as core 0 on socket 0 EAL: Detected lcore 9 as core 1 on socket 0 EAL: Detected lcore 10 as core 2 on socket 0 EAL: Detected lcore 11 as core 3 on socket 0 EAL: Detected lcore 12 as core 4 on socket 0 EAL: Detected lcore 13 as core 5 on socket 0 EAL: Detected lcore 14 as core 6 on socket 0 EAL: Detected lcore 15 as core 7 on socket 0 EAL: Support maximum 16 logical core(s) by configuration. EAL: Detected 16 lcore(s) EAL: VFIO modules not all loaded, skip VFIO support... EAL: Setting up physically contiguous memory... EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fa27460 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fa27420 (size = 0x20) EAL: Ask a virtual area of 0x3c40 bytes EAL: Virtual area found at 0x7fa237c0 (size = 0x3c40) EAL: Ask a virtual area of 0x360 bytes EAL: Virtual area found at 0x7fa23440 (size = 0x360) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fa23400 (size = 0x20) EAL: Ask a virtual area of 0xc000 bytes EAL: Virtual area found at 0x7fa173e0 (size = 0xc000) EAL: Requesting 2048 pages of size 2MB from socket 0 EAL: TSC frequency is ~201 KHz EAL: Master lcore 0 is ready (tid=75a328c0;cpuset=[0]) EAL: lcore 3 is ready (tid=72dfd700;cpuset=[3]) EAL: lcore 1 is ready (tid=73dff700;cpuset=[1]) EAL: lcore 2 is ready (tid=735fe700;cpuset=[2]) EAL: PCI device :03:00.0 on NUMA socket -1 EAL: probe driver: 8086:15ad rte_ixgbe_pmd EAL: Not managed by a supported kernel driver, skipped EAL: PCI device :03:00.1 on NUMA socket -1 EAL: probe driver: 8086:15ad rte_ixgbe_pmd EAL: Not managed by a supported kernel driver, skipped EAL: PCI device :05:00.0 on NUMA socket -1 EAL: probe driver: 8086:1521 rte_igb_pmd EAL: PCI memory mapped at 0x7fa27480 EAL: PCI memory mapped at 0x7fa27482 PMD: eth_igb_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x1521 EAL: PCI device :05:00.1 on NUMA socket -1 EAL: probe driver: 8086:1521 rte_igb_pmd EAL: PCI memory mapped at 0x7fa274824000 EAL: PCI memory mapped at 0x7fa274844000 PMD: eth_igb_dev_init(): port_id 1 vendorID=0x8086 deviceID=0x1521 APP: Port ID: 0 APP: Rx lcore ID: 2, Tx lcore ID: 3 APP: Kernel thread lcore ID: 0 APP: Port ID: 1 APP: Rx lcore ID: 0, Tx lcore ID: 1 APP: Kernel thread lcore ID: 0 EAL: Error - exiting with code: 1 Cause: portmask is not consistent to port ids specified in --config root at x10sdv-f:/opt/dpdk/x86_64-native-linuxapp-gcc/app# we are using dpdk v2.1 at this moment, any suggestions to make this work would be a great help for me. Please let me know if you need more info on this Thanks a lot in advance! Thanks Jaffar
[dpdk-dev] [PATCH] config: cleanup existing RTE_CACHE_LINE_SIZE selection scheme
2015-12-07 19:52, Jerin Jacob: > by default, all the targets will be configured with the 64-byte cache line > size, targets which have different cache line size can be overridden > through target specific config file. > > Selected ThunderX and power8 as CONFIG_RTE_CACHE_LINE_SIZE=128 targets > based on existing configuration. > > Signed-off-by: Jerin Jacob It looks good. We are moving from a constant defined on CC command line in most cases to a constant included in rte_config.h only. Have you checked that the generated libraries are identical? It would be good to have a check for POWER8. Chao? Thanks
[dpdk-dev] [PATCH 0/2] fix performance/cache resource issues with 128-byte cache line targets
2015-12-07 20:03, Jerin Jacob: > On Mon, Dec 07, 2015 at 03:40:13AM -0800, Thomas Monjalon wrote: > > 2015-12-07 12:56, Jerin Jacob: > > > On Sun, Dec 06, 2015 at 05:30:50PM +0100, Thomas Monjalon wrote: > > > > 2015-12-06 21:29, Jerin Jacob: > > > > > This patchset fixes performance/cache resource issues with 128-byte > > > > > cache line targets > > > > > found in mbuf and bitmap DPDK libraries > > > > > > > > > > Currently, we have two DPDK targets(ThunderX and ppc_64) which are > > > > > based on > > > > > 128-bytes cache line size target. > > > > > > > > When introducing IBM Power8, we failed to clean the cache line size > > > > definition. > > > > I promised to not forget this issue in this thread with Neil: > > > > http://dpdk.org/ml/archives/dev/2014-December/009439.html > > > > > > > > It is defined in > > > > config/defconfig_* > > > > mk/machine/*/rte.vars.mk > > > > mk/arch/*/rte.vars.mk > > > > rte_memory.h > > > > rte_kni_common.h > > > > > > > > It should be defined only in the config files. > > > > When we will introduce a configure script, we should be able to detect > > > > it. > > > > > > > > Please Jerin, as ThunderX maintainer, may you help to fix this old mess? > > > > > > Yes Thomas, I will takeup this issue when we will have configure script. > > > > I thought we could start setting the value in only one place. > > The detection in configure script would be another step. > > OK Thomas, I have sent the cleanup patch. Please review it. You are too fast :) I will review it but it will be deferred to 2.3.
[dpdk-dev] [PATCH v2] scripts: support any legal git revisions as abi validation range
2015-12-07 16:09, Panu Matilainen: > On 12/03/2015 04:05 PM, Panu Matilainen wrote: > > In addition to git tags, support validating abi between any legal > > gitrevisions(7) syntaxes, such as "validate-abi.sh -1 . " > > "validate-abi.sh master mybranch " etc in addition to > > validating between tags. Makes it easier to run the validator > > for in-development work. > > > > Signed-off-by: Panu Matilainen > > Acked-by: Neil Horman > > --- > > > > v2 changes: > > - update usage and error messages to match new behavior > > - update documentation too (as suggested by John McNamara) > > > > I started wondering why this didn't get applied along with the other > abi-validator changes and noticed this is sitting in patchwork in > "changes requested" state, which doesn't seem right: v2 added the > requested documentation. It seems to be an error. > The discussion around this patch did spur another request (ability to > pass parallel build flags to make) but that's entirely unrelated, so it > shouldn't hold up this one. Yes > I've no intention of sending a v3 of this patch because AFAIK there's > nothing to fix and the make-flags thing does not belong here, but > resetting the state to "new" by myself feels like cheating or something > :) So what's the correct action here? There's preciously little > documentation about expected patchwork workflow and such. It's not cheating. Changing patchwork status and send such an email looks to be the right thing to do. Yes maybe we can improve the contributing guide. Thanks
[dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource issue with 128-byte cache line targets
Hi Jerin,
> -Original Message-
> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Sunday, December 06, 2015 3:59 PM
> To: dev at dpdk.org
> Cc: thomas.monjalon at 6wind.com; Richardson, Bruce; olivier.matz at
> 6wind.com; Dumitrescu, Cristian; Ananyev, Konstantin; Jerin
> Jacob
> Subject: [dpdk-dev] [PATCH 1/2] mbuf: fix performance/cache resource issue
> with 128-byte cache line targets
>
> No need to split mbuf structure to two cache lines for 128-byte cache line
> size targets as it can fit on a single 128-byte cache line.
>
> Signed-off-by: Jerin Jacob
> ---
> app/test/test_mbuf.c | 4
> lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h | 4
> lib/librte_mbuf/rte_mbuf.h| 2 ++
> 3 files changed, 10 insertions(+)
>
> diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
> index b32bef6..5e21075 100644
> --- a/app/test/test_mbuf.c
> +++ b/app/test/test_mbuf.c
> @@ -930,7 +930,11 @@ test_failing_mbuf_sanity_check(void)
> static int
> test_mbuf(void)
> {
> +#if RTE_CACHE_LINE_SIZE == 64
> RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) != RTE_CACHE_LINE_SIZE * 2);
> +#elif RTE_CACHE_LINE_SIZE == 128
> + RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) != RTE_CACHE_LINE_SIZE);
> +#endif
>
> /* create pktmbuf pool if it does not exist */
> if (pktmbuf_pool == NULL) {
> diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> b/lib/librte_eal/linuxapp/eal/include/exec-
> env/rte_kni_common.h
> index bd1cc09..e724af7 100644
> --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
> @@ -121,8 +121,12 @@ struct rte_kni_mbuf {
> uint32_t pkt_len; /**< Total pkt len: sum of all segment
> data_len. */
> uint16_t data_len; /**< Amount of data in segment buffer. */
>
> +#if RTE_CACHE_LINE_SIZE == 64
> /* fields on second cache line */
> char pad3[8] __attribute__((__aligned__(RTE_CACHE_LINE_SIZE)));
> +#elif RTE_CACHE_LINE_SIZE == 128
> + char pad3[24];
> +#endif
> void *pool;
> void *next;
> };
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index f234ac9..0bf55e0 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -813,8 +813,10 @@ struct rte_mbuf {
>
> uint16_t vlan_tci_outer; /**< Outer VLAN Tag Control Identifier (CPU
> order) */
>
> +#if RTE_CACHE_LINE_SIZE == 64
> /* second cache line - fields only used in slow path or on TX */
> MARKER cacheline1 __rte_cache_aligned;
> +#endif
I suppose you'll need to keep same space reserved for first 64B even on systems
with 128B cache-line.
Otherwise we can endup with different mbuf format for systems with 128B
cache-line.
Another thing - now we have __rte_cache_aligned all over the places, and I
don't know is to double
sizes of all these structures is a good idea.
Again, #if RTE_CACHE_LINE_SIZE == 64 ... all over the places looks a bit
clumsy.
Wonder can we have __rte_cache_aligned/ RTE_CACHE_LINE_SIZE architecture
specific,
but introduce RTE_CACHE_MIN_LINE_SIZE(==64)/ __rte_cache_min_aligned and used
it for mbuf
(and might be other places).
Konstantin
[dpdk-dev] [PATCH v3] scripts: add git hook scripts for checkpatch and auto doc generation
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
---
mk/rte.sdkinstall.mk | 6 +-
scripts/checkpatches.sh | 4
scripts/git-hooks/deploy.sh | 16
scripts/git-hooks/post-commit | 14 ++
scripts/git-hooks/post-merge | 1 +
scripts/git-hooks/pre-commit | 13 +
6 files changed, 53 insertions(+), 1 deletion(-)
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/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index c611d45..8e67c07 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -139,7 +139,11 @@ install-sdk:
tar -xf - -C $(DESTDIR)$(includedir) --strip-components=1 \
--keep-newer-files --warning=no-ignore-newer
$(Q)$(call rte_mkdir,$(DESTDIR)$(sdkdir))
- $(Q)cp -a $(RTE_SDK)/{mk,scripts} $(DESTDIR)$(sdkdir)
+ $(Q)cp -a $(RTE_SDK)/mk$(DESTDIR)$(sdkdir)
+ $(Q)$(call rte_mkdir,
$(DESTDIR)$(sdkdir)/scripts)
+ $(Q)tar -chf - -C $(RTE_SDK) scripts --exclude git-hooks | \
+ tar -xf - -C $(DESTDIR)$(sdkdir)/scripts --strip-components=1 \
+ --keep-newer-files --warning=no-ignore-newer
$(Q)$(call rte_mkdir,$(DESTDIR)$(targetdir))
$(Q)cp -a $O/.config $(DESTDIR)$(targetdir)
$(Q)$(call rte_symlink, $(DESTDIR)$(includedir),
$(DESTDIR)$(targetdir)/include)
diff --git a/scripts/checkpatches.sh b/scripts/checkpatches.sh
index afc611b..6e841ba 100755
--- a/scripts/checkpatches.sh
+++ b/scripts/checkpatches.sh
@@ -66,6 +66,10 @@ while getopts hqv ARG ; do
done
shift $(($OPTIND - 1))
+if [ -z "$@" ]; then
+ exec $DPDK_CHECKPATCH_PATH -q $options -
+fi
+
status=0
for p in "$@" ; do
! $verbose || printf '\n### %s\n\n' "$p"
diff --git a/scripts/git-hooks/deploy.sh b/scripts/git-hooks/deploy.sh
new file mode 100755
index 000..6b0147d
--- /dev/null
+++ b/scripts/git-hooks/deploy.sh
@@ -0,0 +1,16 @@
+
+SELF=$(basename $0)
+
+cd $(dirname $0)
+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..882b3c2
--- /dev/null
+++ b/scripts/git-hooks/post-commit
@@ -0,0 +1,14 @@
+#
+# Create docs after each commit
+#
+
+# Load config options:
+# - DPDK_GITHOOK_DOC_OUT
+. scripts/load-devel-config.sh
+if [ -n "$DPDK_GITHOOK_DOC_OUT" ]; then
+ OUT_CMD="O=${DPDK_GITHOOK_DOC_OUT}"
+fi
+
+echo "Generating documents ..."
+make ${OUT_CMD} doc-guides-html > /dev/null
+make ${OUT_CMD} doc-api-html > /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..f3d6be4
--- /dev/null
+++ b/scripts/git-hooks/pre-commit
@@ -0,0 +1,13 @@
+#
+# Check patch with checkpatch script before commit
+#
+# If checkpatch fails, commit fails
+#
+# Relies on scripts/checkpathes.sh script as checkpatch.pl wrapper
+#
+# It is skipped with the option "--no-verify" of "git commit".
+#
+
+RTE_CHECKPATCH=$PWD/scripts/checkpatches.sh
+
+exec git diff --cached | ${RTE_CHECKPATCH}
--
2.5.0
[dpdk-dev] [PATCH v2] mk: fix external shared library dependencies of drivers, round 2
Panu Matilainen writes:
> Similar to commit 5f9115e58cc6f304ff4ade694cf5823d32887d1a, but
> for qat and mpipe drivers. The former did not exist when the
> previous patch was sent and latter I just missed.
>
> Fixes: 5f9115e58cc6 ("mk: fix shared library dependencies of drivers")
>
> Signed-off-by: Panu Matilainen
> ---
>
> v2:
> - typo/copy-paste error -gxio -> -lgxio
>
> drivers/crypto/qat/Makefile | 1 +
> drivers/net/mpipe/Makefile | 1 +
> mk/rte.app.mk | 8 +---
> 3 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/qat/Makefile b/drivers/crypto/qat/Makefile
> index e027ff9..258c2d5 100644
> --- a/drivers/crypto/qat/Makefile
> +++ b/drivers/crypto/qat/Makefile
> @@ -41,6 +41,7 @@ CFLAGS += $(WERROR_FLAGS)
>
> # external library include paths
> CFLAGS += -I$(SRCDIR)/qat_adf
> +LDLIBS += -lcrypto
>
> # library source files
> SRCS-$(CONFIG_RTE_LIBRTE_PMD_QAT) += qat_crypto.c
> diff --git a/drivers/net/mpipe/Makefile b/drivers/net/mpipe/Makefile
> index 552b303..46f046d 100644
> --- a/drivers/net/mpipe/Makefile
> +++ b/drivers/net/mpipe/Makefile
> @@ -32,6 +32,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
> LIB = librte_pmd_mpipe.a
>
> CFLAGS += $(WERROR_FLAGS) -O3
> +LDLIBS += -lgxio
>
> EXPORT_MAP := rte_pmd_mpipe_version.map
>
> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
> index 90ec33d..856cac0 100644
> --- a/mk/rte.app.mk
> +++ b/mk/rte.app.mk
> @@ -108,6 +108,9 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -libverbs
> _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -libverbs
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += -lsze2
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT)+= -lxenstore
> +# QAT PMD has a dependency on libcrypto (from openssl) for
> calculating HMAC precomputes
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lcrypto
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lgxio
> endif # CONFIG_RTE_BUILD_COMBINE_LIBS or not CONFIG_RTE_BUILD_SHARED_LIBS
>
> _LDLIBS-y += --start-group
> @@ -144,14 +147,13 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_E1000_PMD) +=
> -lrte_pmd_e1000
> _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -lrte_pmd_mlx4
> _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -lrte_pmd_mlx5
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += -lrte_pmd_szedata2
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe -lgxio
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_RING) += -lrte_pmd_ring
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += -lrte_pmd_pcap
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += -lrte_pmd_af_packet
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += -lrte_pmd_null
>
> -# QAT PMD has a dependency on libcrypto (from openssl) for
> calculating HMAC precomputes
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lrte_pmd_qat -lcrypto
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lrte_pmd_qat
>
> # AESNI MULTI BUFFER is dependent on the IPSec_MB library
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += -lrte_pmd_aesni_mb
Acked-by: Aaron Conole
[dpdk-dev] [PATCH] mk: fix warning spew when EXTRA_CFLAGS specifies warning flags
Starting with commit 9aa2053c6e81493b23346ff4e387903560de5c81
EXTRA_CFLAGS is sometimes being passed to the compiler without
WERROR_FLAGS which can cause spurious warnings by the dozen,
for example with when compiling with EXTRA_CFLAGS="-Wformat-security":
cc1: warning: -Wformat-security ignored without -Wformat [-Wformat-security]
Passing WERROR_FLAGS to AUTO_CPU helper makes the warning flag usage
consistent throughout the codebase, silencing the warnings.
Fixes: 9aa2053c6e81 ("mk: influence CPU flags with user input")
Signed-off-by: Panu Matilainen
---
mk/rte.cpuflags.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
index c6bb8de..28f203b 100644
--- a/mk/rte.cpuflags.mk
+++ b/mk/rte.cpuflags.mk
@@ -33,7 +33,7 @@
# used to set the RTE_CPUFLAG_* environment variables giving details
# of what instruction sets the target cpu supports.
-AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(EXTRA_CFLAGS) -dM -E - <
/dev/null)
+AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(WERROR_FLAGS)
$(EXTRA_CFLAGS) -dM -E - < /dev/null)
# adding flags to CPUFLAGS
--
2.5.0
[dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 13:41, Panu Matilainen: > On 12/07/2015 01:28 PM, Thomas Monjalon wrote: > > 2015-12-07 08:29, Panu Matilainen: > >> On 12/07/2015 01:07 AM, Thomas Monjalon wrote: > >>> 2015-12-02 15:53, Panu Matilainen: > >> The vhost ABI break was announced for DPDK 2.2 in commit > >> 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d: > > [...] > >> So the ABI process was properly followed, except for actually bumping > >> LIBABIVER. Bumping LIBABIVER is mentioned in > >> doc/guides/contributing/versioning.rst but it doesn't specify *when* > >> this should be done, eg should the first patch breaking the ABI bump it > >> or should it done be shortly before the next stable release, or > >> something else. As it is, it seems a bit too easy to simply forget. > > > > I thought it was not needed to explicitly say that commits must be atomic > > and we do not have to wait to do the required changes. > > The "problem" is that during a development cycle, an ABI could be broken > several times but LIBABIVER should only be bumped once. So ABI breaking > commits will often not be atomic wrt LIBABIVER, no matter which way its > done. If the ABI version has already been changed, there should be a merge conflict. I think it's better to manage a conflict than forget to update the version. > For example libtool recommendation is that library versions are updated > only just before public releases: > https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info Interesting link. It makes me think that we do not manage ABI break when downgrading the library (case of only new API keeping the ABI number). > > In this case, I've missed it when reviewing the vhost patches breaking the > > ABI.
[dpdk-dev] [PATCH] mk: fix warning spew when EXTRA_CFLAGS specifies warning flags
On 2015-12-07 13:56, Panu Matilainen wrote: > Starting with commit 9aa2053c6e81493b23346ff4e387903560de5c81 > EXTRA_CFLAGS is sometimes being passed to the compiler without > WERROR_FLAGS which can cause spurious warnings by the dozen, > for example with when compiling with EXTRA_CFLAGS="-Wformat-security": > > cc1: warning: -Wformat-security ignored without -Wformat [-Wformat-security] > > Passing WERROR_FLAGS to AUTO_CPU helper makes the warning flag usage > consistent throughout the codebase, silencing the warnings. > [...] > diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk > index c6bb8de..28f203b 100644 > --- a/mk/rte.cpuflags.mk > +++ b/mk/rte.cpuflags.mk > @@ -33,7 +33,7 @@ > # used to set the RTE_CPUFLAG_* environment variables giving details > # of what instruction sets the target cpu supports. > > -AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(EXTRA_CFLAGS) -dM -E - < > /dev/null) > +AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(WERROR_FLAGS) > $(EXTRA_CFLAGS) -dM -E - < /dev/null) Acked-by: Simon Kagstrom
[dpdk-dev] [PATCH] i40e: remove redundant compiler warning disablers
These may have been required at some point but current i40e base driver compiles cleanly without them, at least with clang 3.7.0 and gcc 5.1.1. Signed-off-by: Panu Matilainen --- drivers/net/i40e/Makefile | 13 - 1 file changed, 13 deletions(-) diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile index 033ee4a..4ffaf0d 100644 --- a/drivers/net/i40e/Makefile +++ b/drivers/net/i40e/Makefile @@ -53,23 +53,10 @@ CFLAGS_BASE_DRIVER = -wd593 -wd188 else ifeq ($(CC), clang) CFLAGS_BASE_DRIVER += -Wno-sign-compare CFLAGS_BASE_DRIVER += -Wno-unused-value -CFLAGS_BASE_DRIVER += -Wno-unused-parameter -CFLAGS_BASE_DRIVER += -Wno-strict-aliasing -CFLAGS_BASE_DRIVER += -Wno-format -CFLAGS_BASE_DRIVER += -Wno-missing-field-initializers -CFLAGS_BASE_DRIVER += -Wno-pointer-to-int-cast -CFLAGS_BASE_DRIVER += -Wno-format-nonliteral CFLAGS_BASE_DRIVER += -Wno-unused-variable else CFLAGS_BASE_DRIVER = -Wno-sign-compare CFLAGS_BASE_DRIVER += -Wno-unused-value -CFLAGS_BASE_DRIVER += -Wno-unused-parameter -CFLAGS_BASE_DRIVER += -Wno-strict-aliasing -CFLAGS_BASE_DRIVER += -Wno-format -CFLAGS_BASE_DRIVER += -Wno-missing-field-initializers -CFLAGS_BASE_DRIVER += -Wno-pointer-to-int-cast -CFLAGS_BASE_DRIVER += -Wno-format-nonliteral -CFLAGS_BASE_DRIVER += -Wno-format-security CFLAGS_BASE_DRIVER += -Wno-unused-variable ifeq ($(shell test $(GCC_VERSION) -ge 44 && echo 1), 1) -- 2.5.0
[dpdk-dev] [PATCH v2 1/3] lpm: make rte_lpm_lookupx4 API definition architecture agnostic
On 4 December 2015 at 23:14, Jerin Jacob
wrote:
> -Used architecture agnostic xmm_t to represent 128 bit SIMD variable
>
> -Introduced vect_* API abstraction in app/test to test rte_lpm_lookupx4
> API in architecture agnostic way
>
> -Moved rte_lpm_lookupx4 SSE implementation to architecture specific
> rte_lpm_sse.h file to accommodate new rte_lpm_lookupx4 implementation
> for a different architecture.
>
> Signed-off-by: Jerin Jacob
> ---
> app/test/test_lpm.c | 21 ---
> app/test/test_xmmt_ops.h | 47 ++
> lib/librte_lpm/Makefile | 2 +
> lib/librte_lpm/rte_lpm.h | 93 +---
> lib/librte_lpm/rte_lpm_sse.h | 143
> +++
> 5 files changed, 206 insertions(+), 100 deletions(-)
> create mode 100644 app/test/test_xmmt_ops.h
> create mode 100644 lib/librte_lpm/rte_lpm_sse.h
>
> diff --git a/app/test/test_lpm.c b/app/test/test_lpm.c
> index 8b4ded9..59674f1 100644
> --- a/app/test/test_lpm.c
> +++ b/app/test/test_lpm.c
> @@ -49,6 +49,7 @@
>
> #include "rte_lpm.h"
> #include "test_lpm_routes.h"
> +#include "test_xmmt_ops.h"
>
> #define TEST_LPM_ASSERT(cond) do {
> \
> if (!(cond)) {
> \
> @@ -308,7 +309,7 @@ test6(void)
> int32_t
> test7(void)
> {
> - __m128i ipx4;
> + xmm_t ipx4;
> uint16_t hop[4];
> struct rte_lpm *lpm = NULL;
> uint32_t ip = IPv4(0, 0, 0, 0);
> @@ -324,7 +325,7 @@ test7(void)
> status = rte_lpm_lookup(lpm, ip, _hop_return);
> TEST_LPM_ASSERT((status == 0) && (next_hop_return == next_hop_add));
>
> - ipx4 = _mm_set_epi32(ip, ip + 0x100, ip - 0x100, ip);
> + ipx4 = vect_set_epi32(ip, ip + 0x100, ip - 0x100, ip);
> rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> TEST_LPM_ASSERT(hop[0] == next_hop_add);
> TEST_LPM_ASSERT(hop[1] == UINT16_MAX);
> @@ -354,7 +355,7 @@ test7(void)
> int32_t
> test8(void)
> {
> - __m128i ipx4;
> + xmm_t ipx4;
> uint16_t hop[4];
> struct rte_lpm *lpm = NULL;
> uint32_t ip1 = IPv4(127, 255, 255, 255), ip2 = IPv4(128, 0, 0, 0);
> @@ -380,7 +381,7 @@ test8(void)
> TEST_LPM_ASSERT((status == 0) &&
> (next_hop_return == next_hop_add));
>
> - ipx4 = _mm_set_epi32(ip2, ip1, ip2, ip1);
> + ipx4 = vect_set_epi32(ip2, ip1, ip2, ip1);
> rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> TEST_LPM_ASSERT(hop[0] == UINT16_MAX);
> TEST_LPM_ASSERT(hop[1] == next_hop_add);
> @@ -408,7 +409,7 @@ test8(void)
> status = rte_lpm_lookup(lpm, ip1, _hop_return);
> TEST_LPM_ASSERT(status == -ENOENT);
>
> - ipx4 = _mm_set_epi32(ip1, ip1, ip2, ip2);
> + ipx4 = vect_set_epi32(ip1, ip1, ip2, ip2);
> rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> if (depth != 1) {
> TEST_LPM_ASSERT(hop[0] == next_hop_add);
> @@ -850,7 +851,7 @@ test11(void)
> int32_t
> test12(void)
> {
> - __m128i ipx4;
> + xmm_t ipx4;
> uint16_t hop[4];
> struct rte_lpm *lpm = NULL;
> uint32_t ip, i;
> @@ -872,7 +873,7 @@ test12(void)
> TEST_LPM_ASSERT((status == 0) &&
> (next_hop_return == next_hop_add));
>
> - ipx4 = _mm_set_epi32(ip, ip + 1, ip, ip - 1);
> + ipx4 = vect_set_epi32(ip, ip + 1, ip, ip - 1);
> rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> TEST_LPM_ASSERT(hop[0] == UINT16_MAX);
> TEST_LPM_ASSERT(hop[1] == next_hop_add);
> @@ -1289,10 +1290,10 @@ perf_test(void)
> begin = rte_rdtsc();
> for (j = 0; j < BATCH_SIZE; j += RTE_DIM(next_hops)) {
> unsigned k;
> - __m128i ipx4;
> + xmm_t ipx4;
>
> - ipx4 = _mm_loadu_si128((__m128i *)(ip_batch + j));
> - ipx4 = *(__m128i *)(ip_batch + j);
> + ipx4 = vect_loadu_sil128((xmm_t *)(ip_batch + j));
> + ipx4 = *(xmm_t *)(ip_batch + j);
> rte_lpm_lookupx4(lpm, ipx4, next_hops, UINT16_MAX);
> for (k = 0; k < RTE_DIM(next_hops); k++)
> if (unlikely(next_hops[k] == UINT16_MAX))
> diff --git a/app/test/test_xmmt_ops.h b/app/test/test_xmmt_ops.h
> new file mode 100644
> index 000..c055912
> --- /dev/null
> +++ b/app/test/test_xmmt_ops.h
Why add this new file under app/test, which is only for test app?
Should vect_loadu_sil128/vect_set_epi32 be in each ARCH's rte_vect.h?
> @@ -0,0 +1,47 @@
> +/*-
> + * BSD LICENSE
> + *
> + * Copyright(c) 2015 Cavium Networks. All rights reserved.
>
[dpdk-dev] [PATCH v2 1/3] lpm: make rte_lpm_lookupx4 API definition architecture agnostic
> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com] > Sent: Friday, December 04, 2015 3:15 PM > To: dev at dpdk.org > Cc: thomas.monjalon at 6wind.com; Ananyev, Konstantin; viktorin at > rehivetech.com; jianbo.liu at linaro.org; Jerin Jacob > Subject: [dpdk-dev] [PATCH v2 1/3] lpm: make rte_lpm_lookupx4 API definition > architecture agnostic > > -Used architecture agnostic xmm_t to represent 128 bit SIMD variable > > -Introduced vect_* API abstraction in app/test to test rte_lpm_lookupx4 > API in architecture agnostic way > > -Moved rte_lpm_lookupx4 SSE implementation to architecture specific > rte_lpm_sse.h file to accommodate new rte_lpm_lookupx4 implementation > for a different architecture. > > Signed-off-by: Jerin Jacob > --- Acked-by: Konstantin Ananyev
[dpdk-dev] [PATCH v10 4/4] doc: add user-space ethtool sample app guide
Signed-off-by: Remy Horton
---
doc/guides/rel_notes/release_2_2.rst | 1 +
doc/guides/sample_app_ug/ethtool.rst | 160 +++
doc/guides/sample_app_ug/index.rst | 1 +
3 files changed, 162 insertions(+)
create mode 100644 doc/guides/sample_app_ug/ethtool.rst
diff --git a/doc/guides/rel_notes/release_2_2.rst
b/doc/guides/rel_notes/release_2_2.rst
index 34237b9..a07b8e0 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -243,6 +243,7 @@ Examples
* **vhost_xen: Fixed compile error.**
+* **ethtool: Added ethtool shim and sample application.**
Other
~
diff --git a/doc/guides/sample_app_ug/ethtool.rst
b/doc/guides/sample_app_ug/ethtool.rst
new file mode 100644
index 000..4d1697e
--- /dev/null
+++ b/doc/guides/sample_app_ug/ethtool.rst
@@ -0,0 +1,160 @@
+
+.. BSD LICENSE
+Copyright(c) 2015 Intel Corporation. All rights reserved.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of Intel Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Ethtool Sample Application
+==
+
+The Ethtool sample application shows an implementation of an
+ethtool-like API and provides a console environment that allows
+its use to query and change Ethernet card parameters. The sample
+is based upon a simple L2 frame reflector.
+
+Compiling the Application
+-
+
+To compile the application:
+
+#. Go to the sample application directory:
+
+.. code-block:: console
+
+export RTE_SDK=/path/to/rte_sdk
+cd ${RTE_SD}/examples/ethtool
+
+#. Set the target (a default target is used if not specified). For example:
+
+.. code-block:: console
+
+export RTE_TARGET=x86_64-native-linuxapp-gcc
+
+See the *DPDK Getting Started Guide* for possible RTE_TARGET values.
+
+#. Build the application:
+
+.. code-block:: console
+
+make
+
+Running the Application
+---
+
+The application requires an available core for each port, plus one.
+The only available options are the standard ones for the EAL:
+
+.. code-block:: console
+
+./ethtool-app/ethtool-app/${RTE_TARGET}/ethtool [EAL options]
+
+Refer to the *DPDK Getting Started Guide* for general information on
+running applications and the Environment Abstraction Layer (EAL)
+options.
+
+Using the application
+-
+
+The application is console-driven using the cmdline DPDK interface:
+
+.. code-block:: console
+
+EthApp>
+
+From this interface the available commands and descriptions of what
+they do as as follows:
+
+* ``drvinfo``: Print driver info
+* ``eeprom``: Dump EEPROM to file
+* ``link``: Print port link states
+* ``macaddr``: Gets/sets MAC address
+* ``mtu``: Set NIC MTU
+* ``open``: Open port
+* ``pause``: Get/set port pause state
+* ``portstats``: Print port statistics
+* ``regs``: Dump port register(s) to file
+* ``ringparam``: Get/set ring parameters
+* ``rxmode``: Toggle port Rx mode
+* ``stop``: Stop port
+* ``validate``: Check that given MAC address is valid unicast address
+* ``vlan``: Add/remove VLAN id
+* ``quit``: Exit program
+
+
+Explanation
+---
+
+The sample program has two parts: A background `packet reflector`_
+that runs on a slave core, and a foreground `Ethtool Shell`_ that
+runs on the master core. These are described below.
+
+Packet Reflector
+
+
+The background packet reflector is intended to demonstrate basic
+packet processing on NIC ports controlled by the Ethtool shim.
+Each
[dpdk-dev] [PATCH v10 3/4] example: add user-space ethtool sample application
Further enhancements to the userspace ethtool implementation that was submitted in 2.1 and packaged as a self-contained sample application. Implements an rte_ethtool shim layer based on rte_ethdev API, along with a command prompt driven demonstration application. Signed-off-by: Remy Horton --- MAINTAINERS | 4 + examples/Makefile | 1 + examples/ethtool/Makefile | 48 ++ examples/ethtool/ethtool-app/Makefile | 54 +++ examples/ethtool/ethtool-app/ethapp.c | 873 ++ examples/ethtool/ethtool-app/ethapp.h | 41 ++ examples/ethtool/ethtool-app/main.c | 305 examples/ethtool/lib/Makefile | 57 +++ examples/ethtool/lib/rte_ethtool.c| 423 examples/ethtool/lib/rte_ethtool.h| 410 10 files changed, 2216 insertions(+) create mode 100644 examples/ethtool/Makefile create mode 100644 examples/ethtool/ethtool-app/Makefile create mode 100644 examples/ethtool/ethtool-app/ethapp.c create mode 100644 examples/ethtool/ethtool-app/ethapp.h create mode 100644 examples/ethtool/ethtool-app/main.c create mode 100644 examples/ethtool/lib/Makefile create mode 100644 examples/ethtool/lib/rte_ethtool.c create mode 100644 examples/ethtool/lib/rte_ethtool.h diff --git a/MAINTAINERS b/MAINTAINERS index 8319ce1..3fcccbc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -575,3 +575,7 @@ F: doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst M: Pablo de Lara M: Daniel Mrzyglod F: examples/ptpclient/ + +M: Remy Horton +F: examples/ethtool/ +F: doc/guides/sample_app_ug/ethtool.rst diff --git a/examples/Makefile b/examples/Makefile index 5dd2c53..1cb4785 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -43,6 +43,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += distributor ifneq ($(ICP_ROOT),) DIRS-y += dpdk_qat endif +DIRS-y += ethtool DIRS-y += exception_path DIRS-y += helloworld DIRS-y += ip_pipeline diff --git a/examples/ethtool/Makefile b/examples/ethtool/Makefile new file mode 100644 index 000..94f8ee3 --- /dev/null +++ b/examples/ethtool/Makefile @@ -0,0 +1,48 @@ +# BSD LICENSE +# +# Copyright(c) 2015 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +ifeq ($(RTE_SDK),) +$(error "Please define RTE_SDK environment variable") +endif + +# Default target, can be overwritten by command line or environment +RTE_TARGET ?= x86_64-native-linuxapp-gcc + +include $(RTE_SDK)/mk/rte.vars.mk + +ifneq ($(CONFIG_RTE_EXEC_ENV),"linuxapp") +$(error This application can only operate in a linuxapp environment, \ +please change the definition of the RTE_TARGET environment variable) +endif + +DIRS-y += lib ethtool-app + +include $(RTE_SDK)/mk/rte.extsubdir.mk diff --git a/examples/ethtool/ethtool-app/Makefile b/examples/ethtool/ethtool-app/Makefile new file mode 100644 index 000..09c66ad --- /dev/null +++ b/examples/ethtool/ethtool-app/Makefile @@ -0,0 +1,54 @@ +# BSD LICENSE +# +# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in
[dpdk-dev] [PATCH v10 2/4] mk: Fix missing directory with combined extlib build
Signed-off-by: Remy Horton --- mk/rte.extlib.mk | 6 ++ 1 file changed, 6 insertions(+) diff --git a/mk/rte.extlib.mk b/mk/rte.extlib.mk index 4d459e4..47023a3 100644 --- a/mk/rte.extlib.mk +++ b/mk/rte.extlib.mk @@ -42,11 +42,17 @@ export NOT_FIRST_CALL all: $(Q)mkdir -p $(RTE_OUTPUT) +ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) + $(Q)mkdir -p $(RTE_OUTPUT)/build/lib +endif $(Q)$(MAKE) -C $(RTE_OUTPUT) -f $(RTE_EXTMK) \ S=$(RTE_SRCDIR) O=$(RTE_OUTPUT) SRCDIR=$(RTE_SRCDIR) %:: $(Q)mkdir -p $(RTE_OUTPUT) +ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) + $(Q)mkdir -p $(RTE_OUTPUT)/build/lib +endif $(Q)$(MAKE) -C $(RTE_OUTPUT) -f $(RTE_EXTMK) $@ \ S=$(RTE_SRCDIR) O=$(RTE_OUTPUT) SRCDIR=$(RTE_SRCDIR) else -- 1.9.3
[dpdk-dev] [PATCH v10 0/4] User-space ethtool sample application
Further enhancements to the userspace ethtool implementation that was submitted in 2.1 and packaged as a self-contained sample application. Implements an rte_ethtool shim layer based on rte_ethdev API, along with a command prompt driven demonstration application. This patchset depends on: * http://dpdk.org/dev/patchwork/patch/8070/ v10: * Fixed non-creation of sub-dirs needed for combined lib build * Rebased to latest origin/master v9: * Merged in upstream external lib dependency * Added sanity check to shim MTU set function * Added example to example/Makefile * Rebased to latest master v8: * Rebased to latest origin/master v7: * Ringparam printouts wrong way round * Ringparam help message corrections * Use __rte_unused instead of __attribute__((unused)) * Allow Jumbo-sized MTUs * Documentation style and spelling changes v6: * Fixed hang when run with zero available ports * Fixed incorrect sanity check preventing EEPROM dumps * Documentation additions * Fixed RxMode accepting untagged packets * Fixed ringparam allocation being too small v5: * Documentation changes v4: * Fixed assumption that master core always has id zero * Changed 1:1 core-to-port to 2 core (ethtool & ports) design * Included the correct documentation.. v3: * Made use of enums for core state. * Fixed Makefile issue. * Fixed incorrect assumption with core ids. * Changed handling of more ports than cores. v2: * Replaced l2fwd base with simpler application. * Added ringparam functions. * Added documentation. Remy Horton (4): Remove ABI requirement for external library builds. mk: Fix missing directory with combined extlib build example: add user-space ethtool sample application doc: add user-space ethtool sample app guide & release notes MAINTAINERS | 4 + doc/guides/rel_notes/release_2_2.rst | 1 + doc/guides/sample_app_ug/ethtool.rst | 160 +++ doc/guides/sample_app_ug/index.rst| 1 + examples/Makefile | 1 + examples/ethtool/Makefile | 48 ++ examples/ethtool/ethtool-app/Makefile | 54 +++ examples/ethtool/ethtool-app/ethapp.c | 873 ++ examples/ethtool/ethtool-app/ethapp.h | 41 ++ examples/ethtool/ethtool-app/main.c | 305 examples/ethtool/lib/Makefile | 57 +++ examples/ethtool/lib/rte_ethtool.c| 423 examples/ethtool/lib/rte_ethtool.h| 410 mk/rte.extlib.mk | 8 + mk/rte.lib.mk | 6 + 15 files changed, 2392 insertions(+) create mode 100644 doc/guides/sample_app_ug/ethtool.rst create mode 100644 examples/ethtool/Makefile create mode 100644 examples/ethtool/ethtool-app/Makefile create mode 100644 examples/ethtool/ethtool-app/ethapp.c create mode 100644 examples/ethtool/ethtool-app/ethapp.h create mode 100644 examples/ethtool/ethtool-app/main.c create mode 100644 examples/ethtool/lib/Makefile create mode 100644 examples/ethtool/lib/rte_ethtool.c create mode 100644 examples/ethtool/lib/rte_ethtool.h -- 1.9.3
[dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
On 12/07/2015 01:28 PM, Thomas Monjalon wrote: > 2015-12-07 08:29, Panu Matilainen: >> On 12/07/2015 01:07 AM, Thomas Monjalon wrote: >>> 2015-12-02 15:53, Panu Matilainen: This (and other changes in patch 2 breaks the librte_vhost ABI again, so you'd need to at least add a deprecation note to 2.2 to be able to do it in 2.3 at all according to the ABI policy. Perhaps a better option would be adding some padding to the structs now for 2.2 since the vhost ABI is broken there anyway. That would at least give a chance to keep it compatible from 2.2 to 2.3. >>> >>> Please could you point where the vhost ABI is broken in 2.2? >>> >> >> The vhost ABI break was announced for DPDK 2.2 in commit >> 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d: > [...] >> So the ABI process was properly followed, except for actually bumping >> LIBABIVER. Bumping LIBABIVER is mentioned in >> doc/guides/contributing/versioning.rst but it doesn't specify *when* >> this should be done, eg should the first patch breaking the ABI bump it >> or should it done be shortly before the next stable release, or >> something else. As it is, it seems a bit too easy to simply forget. > > I thought it was not needed to explicitly say that commits must be atomic > and we do not have to wait to do the required changes. The "problem" is that during a development cycle, an ABI could be broken several times but LIBABIVER should only be bumped once. So ABI breaking commits will often not be atomic wrt LIBABIVER, no matter which way its done. For example libtool recommendation is that library versions are updated only just before public releases: https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info - Panu - > In this case, I've missed it when reviewing the vhost patches breaking the > ABI. >
[dpdk-dev] [PATCH v2] scripts: add git hook scripts for checkpatch and auto doc generation
On Thu, Dec 03, 2015 at 11:09:30AM -0800, Thomas Monjalon wrote:
> Ferruh,
> I have a lot of questions :)
>
> 2015-11-27 14:34, Ferruh Yigit:
> > --- 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}"
>
> What is the purpose of this variable?
> Why adding some options would be specific to git hooks?
>
When you use "commit -s", sign-off msg added after this script run,
also when you do "commit --ammend" that piece of patch does not have sign-off
part,
so pre-commit hook can have problems with sign-off check and git hook specific
option is to pass --no-signoff option.
> > +++ 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
>
> You do not need to exit. Just cd $(dirname $0).
>
Thanks, I will do that.
> > +for f in ${FILES}; do
> > + ln -sf ${SCRIPT_FOLDER}/${f} ${TARGET_FOLDER}/${f}
> > +done;
>
> You do not need the ;
>
OK
> > --- /dev/null
> > +++ b/scripts/git-hooks/post-commit
> > +if [ -n "$RTE_DOC_OUT" ]; then
> > + OUT_CMD="O=${RTE_DOC_OUT}"
> > +fi
>
> How to pass RTE_DOC_OUT to the hook?
> Why not use load-devel-config.sh?
>
It is possbile pass by exporting it as environment variable,
but since load-devel-config is already there, I will use it.
> > +make ${OUT_CMD} doc-guides-html 2>&1 > /dev/null
> > +make ${OUT_CMD} doc-api-html 2>&1 > /dev/null
>
> Why hiding the errors?
>
To prevent noise, but I double check and enabling error messages not noisy, so
I will enable it.
> > --- /dev/null
> > +++ b/scripts/git-hooks/post-merge
>
> Does it work for "git pull --rebase"?
No, it is not working, for that pre-rebase is required,
easy to create a link for that but I am not sure about increasing number of
hooks,
with pre-rebase hook, an internal rebase too will trigger doc generation, which
is not good I believe.
>
> > --- /dev/null
> > +++ b/scripts/git-hooks/pre-commit
> > +# If "git commit" called with "--no-verify" option, pre-commit hooks
> > +# bypassed and this script not called, checkpatch bypassed
>
> Possible reword: It is skipped with the option "--no-verify" of "git commit".
>
OK, thanks.
> > +RTE_CHECKPATCH=$PWD/scripts/checkpatches.sh
>
> What is PWD when calling the hook. May it be a subdir?
>
Even you call git commands from a subdir, git hooks scripts run from root dir,
so this will be always correct.
> > +PATCH=/tmp/dpdk-git-auto-checkpatch-$$.patch
>
> You need to remove this temporary file when exiting.
> But it would be better to use stdin.
> It may need a patch on checkpatches.sh wrapper.
> In chekpatch.pl: "When FILE is - read standard input".
>
I also prefer using stdin, and previous patch was like that,
but checkpatches.sh requires a file, let me check possible update in
checkpatches.sh
> > +export GIT_HOOK_OPTIONS=--no-signoff
>
> This variable is wrongly named.
>
Will rename.
> > +git diff --cached > ${PATCH}
> > +exec ${RTE_CHECKPATCH} ${PATCH}
>
> When the new "make install" will be applied, I think we should skip
> these files. Please consider patching mk/rte.sdkinstall.mk.
ok, I will update skdinstall.mk
Thanks for the review.
ferruh
[dpdk-dev] [PATCH v4] ip_pipeline: add flow actions pipeline
2015-12-07 09:44, Singh, Jasvinder: > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > > Flow actions pipeline is an extension of flow-classification pipeline. > > > Some of the operations of flow classification pipeline such as traffic > > > > > > Signed-off-by: Jasvinder Singh > > > Signed-off-by: Fan Zhang > > > Acked-by: Cristian Dumitrescu > > > > Applied, thanks > > Hi Thomas, > > This patch is not merged in the master. I don't see any source file. Sorry for the inconvenience. I had to resolve some conflicts and forgot to "git add" some files. It is fixed now. Thank you for reporting.
[dpdk-dev] [PATCH 0/2] fix performance/cache resource issues with 128-byte cache line targets
On Sun, Dec 06, 2015 at 05:30:50PM +0100, Thomas Monjalon wrote: > 2015-12-06 21:29, Jerin Jacob: > > This patchset fixes performance/cache resource issues with 128-byte cache > > line targets > > found in mbuf and bitmap DPDK libraries > > > > Currently, we have two DPDK targets(ThunderX and ppc_64) which are based on > > 128-bytes cache line size target. > > When introducing IBM Power8, we failed to clean the cache line size > definition. > I promised to not forget this issue in this thread with Neil: > http://dpdk.org/ml/archives/dev/2014-December/009439.html > > It is defined in > config/defconfig_* > mk/machine/*/rte.vars.mk > mk/arch/*/rte.vars.mk > rte_memory.h > rte_kni_common.h > > It should be defined only in the config files. > When we will introduce a configure script, we should be able to detect it. > > Please Jerin, as ThunderX maintainer, may you help to fix this old mess? Yes Thomas, I will takeup this issue when we will have configure script. apart from that, content of the this patch will be still valid as the fix going to be generating cache line define from the config file. Jerin > Thanks
[dpdk-dev] [PATCH v3 2/2] eal/linux: Add support for handling built-in kernel modules
On Mon, 7 Dec 2015 19:36:05 +0100
Kamil Rytarowski wrote:
> + /* Check if there is sysfs mounted */
> + if (stat("/sys/module", ) != 0) {
> + RTE_LOG(DEBUG, EAL, "Open /sys/module failed: %s\n",
> + strerror(errno));
> return -1;
> }
This check is useless.
If /sys/module does not exist then /sys/module/XXX won't exist either.
[dpdk-dev] [PATCH v2] mk: pass EXTRA_CFLAGS to AUTO_CPUFLAGS to enable local modifications
2015-12-07 10:33, Panu Matilainen: > On 12/04/2015 08:53 PM, Thomas Monjalon wrote: > We have encountered a CPU where the AES-NI instruction set is disabled > due to export restrictions. Since the build machine and target machine > is different, using -native configs doesn't work, and on this CPU, the > application refuses to run due to the AES CPU flags being amiss. > > The patch passes EXTRA_CFLAGS to the figure-out-cpu-flags helper, > which allows us to add -mno-aes to the compile flags and resolve this > problem. > > Signed-off-by: Simon Kagstrom > >> > >> Acked-by: Olivier Matz > > > > Applied, thanks > > > > This causes some complications on Fedora/RHEL due to fairly complex > interactions with -Werror, -Wall and -Wformat-security mixup between > upstream- and distro default compiler flags. > > More specifically, when EXTRA_CFLAGS contains warning flag manipulation > this patch can cause mismatch between other options that are okay > elsewhere in dpdk make. A simple fix is to pass WERROR_FLAGS to > AUTO_CPUFLAGS too to counter this, ie > > diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk > index c6bb8de..28f203b 100644 > --- a/mk/rte.cpuflags.mk > +++ b/mk/rte.cpuflags.mk > @@ -33,7 +33,7 @@ > # used to set the RTE_CPUFLAG_* environment variables giving details > # of what instruction sets the target cpu supports. > > -AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(EXTRA_CFLAGS) -dM -E > - < /dev/null) > +AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(WERROR_FLAGS) > $(EXTRA_CFLAGS) -dM -E - < /dev/null) > > # adding flags to CPUFLAGS > > > I can send an official patch if this seems acceptable. Yes this is acceptable. Please explain the error you see in the commit message.
[dpdk-dev] [PATCH v2] mk: pass EXTRA_CFLAGS to AUTO_CPUFLAGS to enable local modifications
On 2015-12-07 09:33, Panu Matilainen wrote: > On 12/04/2015 08:53 PM, Thomas Monjalon wrote: > We have encountered a CPU where the AES-NI instruction set is disabled > due to export restrictions. Since the build machine and target machine > is different, using -native configs doesn't work, and on this CPU, the > application refuses to run due to the AES CPU flags being amiss. > > The patch passes EXTRA_CFLAGS to the figure-out-cpu-flags helper, > which allows us to add -mno-aes to the compile flags and resolve this > problem. > > More specifically, when EXTRA_CFLAGS contains warning flag manipulation > this patch can cause mismatch between other options that are okay > elsewhere in dpdk make. A simple fix is to pass WERROR_FLAGS to > AUTO_CPUFLAGS too to counter this, ie > > diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk > index c6bb8de..28f203b 100644 > --- a/mk/rte.cpuflags.mk > +++ b/mk/rte.cpuflags.mk > @@ -33,7 +33,7 @@ > # used to set the RTE_CPUFLAG_* environment variables giving details > # of what instruction sets the target cpu supports. > > -AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(EXTRA_CFLAGS) -dM -E > - < /dev/null) > +AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(WERROR_FLAGS) > $(EXTRA_CFLAGS) -dM -E - < /dev/null) Looks fine to me at least. // Simon
[dpdk-dev] [PATCH v2] mk: fix external shared library dependencies of drivers, round 2
Similar to commit 5f9115e58cc6f304ff4ade694cf5823d32887d1a, but
for qat and mpipe drivers. The former did not exist when the
previous patch was sent and latter I just missed.
Fixes: 5f9115e58cc6 ("mk: fix shared library dependencies of drivers")
Signed-off-by: Panu Matilainen
---
v2:
- typo/copy-paste error -gxio -> -lgxio
drivers/crypto/qat/Makefile | 1 +
drivers/net/mpipe/Makefile | 1 +
mk/rte.app.mk | 8 +---
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/qat/Makefile b/drivers/crypto/qat/Makefile
index e027ff9..258c2d5 100644
--- a/drivers/crypto/qat/Makefile
+++ b/drivers/crypto/qat/Makefile
@@ -41,6 +41,7 @@ CFLAGS += $(WERROR_FLAGS)
# external library include paths
CFLAGS += -I$(SRCDIR)/qat_adf
+LDLIBS += -lcrypto
# library source files
SRCS-$(CONFIG_RTE_LIBRTE_PMD_QAT) += qat_crypto.c
diff --git a/drivers/net/mpipe/Makefile b/drivers/net/mpipe/Makefile
index 552b303..46f046d 100644
--- a/drivers/net/mpipe/Makefile
+++ b/drivers/net/mpipe/Makefile
@@ -32,6 +32,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_pmd_mpipe.a
CFLAGS += $(WERROR_FLAGS) -O3
+LDLIBS += -lgxio
EXPORT_MAP := rte_pmd_mpipe_version.map
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 90ec33d..856cac0 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -108,6 +108,9 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -libverbs
_LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -libverbs
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += -lsze2
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT)+= -lxenstore
+# QAT PMD has a dependency on libcrypto (from openssl) for calculating HMAC
precomputes
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lcrypto
+_LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lgxio
endif # CONFIG_RTE_BUILD_COMBINE_LIBS or not CONFIG_RTE_BUILD_SHARED_LIBS
_LDLIBS-y += --start-group
@@ -144,14 +147,13 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_E1000_PMD) +=
-lrte_pmd_e1000
_LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -lrte_pmd_mlx4
_LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -lrte_pmd_mlx5
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += -lrte_pmd_szedata2
-_LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe -lgxio
+_LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_RING) += -lrte_pmd_ring
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += -lrte_pmd_pcap
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += -lrte_pmd_af_packet
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += -lrte_pmd_null
-# QAT PMD has a dependency on libcrypto (from openssl) for calculating HMAC
precomputes
-_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lrte_pmd_qat -lcrypto
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lrte_pmd_qat
# AESNI MULTI BUFFER is dependent on the IPSec_MB library
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += -lrte_pmd_aesni_mb
--
2.5.0
[dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
2015-12-07 07:47, Liu, Jijiang: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2015-12-07 03:30, Liu, Jijiang: > > > Hi Thomas, > > > > > > > -Original Message- > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > Sent: Monday, December 07, 2015 11:17 AM > > > > To: Liu, Jijiang > > > > Cc: dev at dpdk.org > > > > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct > > > > rte_eth_conf > > > > > > > > 2015-12-07 11:01, Jijiang Liu: > > > > > +* ABI changes are planned for struct rte_eth_conf in order to > > > > > +support > > > > > + tunneling packet configuration in unified tunneling API. The > > > > > +release 2.2 > > > > does not contain these ABI > > > > > + changes, but release 2.3 will, and no backwards compatibility is > > planned. > > > > > > > > Please, more details would be appreciated. > > > > We need to decide whether an ABI deprecation is the right choice. > > > > > > * ABI changes are planned for struct rte_eth_conf in order to support > > > tunneling packet configuration in unified tunneling APIs, which is the > > rte_eth_dev_tunnel_configure > > > (uint8_t port_id, uint16_t rx_q, uint16_t tx_q, rte_eth_tunnel_conf * > > tunnel_conf) API is planned to add. > > > and the 'tunnel_conf' shloud be stored in global 'rte_eth_conf'. > > > The release 2.2 does not contain these ABI change, but release 2.3 will, > > and no backwards compatibility is planned. > > > > > > Is it enough clear? > > > > No, I think we need an explanation in the commit message of what is the > > purpose of rte_eth_dev_tunnel_configure() and tunnel_conf. > Ok, will do. > > Ideally, an RFC patch would help. > I'm working on RFC patch, but it probably will miss merge timeslot of this > release. A RFC patch may be incomplete. The API changes are enough.
[dpdk-dev] Meaning of ETH_TXQ_FLAGS_NOREFCOUNT
Hello,
I would have thought that ETH_TXQ_FLAGS_NOREFCOUNT,
when enabled, would mean to ignore ref counts, as commented
in rte_ethdev.h:
#define ETH_TXQ_FLAGS_NOREFCOUNT 0x0002 /**< refcnt can be ignored */
But it seems to be used differently:
if (!(txq->txq_flags & (uint32_t)ETH_TXQ_FLAGS_NOREFCOUNT)) {
for (i = 0; i < txq->tx_rs_thresh; ++i, ++txep) {
rte_mempool_put(txep->mbuf->pool, txep->mbuf);
txep->mbuf = NULL;
}
So that if its -not- set, then rte_mempool_put() is called, and if it
is set then rte_pktmbuf_free_seg() is called.
Also, it seems to be used the same way in both the i40e driver
and the ixgbe driver: when its set it decr's the refcount, when
its unset it ignores the refcnt, but these are the only two drivers
which seem to honor the flag.
Any chance of getting a little more information the intent here?
regards,
mts.
[dpdk-dev] [PATCH] mk: fix external shared library dependencies of drivers, round 2
Similar to commit 5f9115e58cc6f304ff4ade694cf5823d32887d1a, but
for qat and mpipe drivers. The former did not exist when the
previous patch was sent and latter I just missed.
Fixes: 5f9115e58cc6 ("mk: fix shared library dependencies of drivers")
Signed-off-by: Panu Matilainen
---
drivers/crypto/qat/Makefile | 1 +
drivers/net/mpipe/Makefile | 1 +
mk/rte.app.mk | 8 +---
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/qat/Makefile b/drivers/crypto/qat/Makefile
index e027ff9..258c2d5 100644
--- a/drivers/crypto/qat/Makefile
+++ b/drivers/crypto/qat/Makefile
@@ -41,6 +41,7 @@ CFLAGS += $(WERROR_FLAGS)
# external library include paths
CFLAGS += -I$(SRCDIR)/qat_adf
+LDLIBS += -lcrypto
# library source files
SRCS-$(CONFIG_RTE_LIBRTE_PMD_QAT) += qat_crypto.c
diff --git a/drivers/net/mpipe/Makefile b/drivers/net/mpipe/Makefile
index 552b303..654d191 100644
--- a/drivers/net/mpipe/Makefile
+++ b/drivers/net/mpipe/Makefile
@@ -32,6 +32,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_pmd_mpipe.a
CFLAGS += $(WERROR_FLAGS) -O3
+LDLIBS += -gxio
EXPORT_MAP := rte_pmd_mpipe_version.map
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index 90ec33d..856cac0 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -108,6 +108,9 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -libverbs
_LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -libverbs
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += -lsze2
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT)+= -lxenstore
+# QAT PMD has a dependency on libcrypto (from openssl) for calculating HMAC
precomputes
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lcrypto
+_LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lgxio
endif # CONFIG_RTE_BUILD_COMBINE_LIBS or not CONFIG_RTE_BUILD_SHARED_LIBS
_LDLIBS-y += --start-group
@@ -144,14 +147,13 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_E1000_PMD) +=
-lrte_pmd_e1000
_LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -lrte_pmd_mlx4
_LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -lrte_pmd_mlx5
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SZEDATA2) += -lrte_pmd_szedata2
-_LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe -lgxio
+_LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_RING) += -lrte_pmd_ring
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += -lrte_pmd_pcap
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) += -lrte_pmd_af_packet
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NULL) += -lrte_pmd_null
-# QAT PMD has a dependency on libcrypto (from openssl) for calculating HMAC
precomputes
-_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lrte_pmd_qat -lcrypto
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lrte_pmd_qat
# AESNI MULTI BUFFER is dependent on the IPSec_MB library
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += -lrte_pmd_aesni_mb
--
2.5.0
[dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 08:29, Panu Matilainen: > On 12/07/2015 01:07 AM, Thomas Monjalon wrote: > > 2015-12-02 15:53, Panu Matilainen: > >> This (and other changes in patch 2 breaks the librte_vhost ABI again, so > >> you'd need to at least add a deprecation note to 2.2 to be able to do it > >> in 2.3 at all according to the ABI policy. > >> > >> Perhaps a better option would be adding some padding to the structs now > >> for 2.2 since the vhost ABI is broken there anyway. That would at least > >> give a chance to keep it compatible from 2.2 to 2.3. > > > > Please could you point where the vhost ABI is broken in 2.2? > > > > The vhost ABI break was announced for DPDK 2.2 in commit > 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d: [...] > So the ABI process was properly followed, except for actually bumping > LIBABIVER. Bumping LIBABIVER is mentioned in > doc/guides/contributing/versioning.rst but it doesn't specify *when* > this should be done, eg should the first patch breaking the ABI bump it > or should it done be shortly before the next stable release, or > something else. As it is, it seems a bit too easy to simply forget. I thought it was not needed to explicitly say that commits must be atomic and we do not have to wait to do the required changes. In this case, I've missed it when reviewing the vhost patches breaking the ABI.
[dpdk-dev] [PATCH v2 1/3] lpm: make rte_lpm_lookupx4 API definition architecture agnostic
On Mon, Dec 07, 2015 at 02:15:28PM +0800, Jianbo Liu wrote:
> On 4 December 2015 at 23:14, Jerin Jacob
> wrote:
> > -Used architecture agnostic xmm_t to represent 128 bit SIMD variable
> >
> > -Introduced vect_* API abstraction in app/test to test rte_lpm_lookupx4
> > API in architecture agnostic way
> >
> > -Moved rte_lpm_lookupx4 SSE implementation to architecture specific
> > rte_lpm_sse.h file to accommodate new rte_lpm_lookupx4 implementation
> > for a different architecture.
> >
> > Signed-off-by: Jerin Jacob
> > ---
> > app/test/test_lpm.c | 21 ---
> > app/test/test_xmmt_ops.h | 47 ++
> > lib/librte_lpm/Makefile | 2 +
> > lib/librte_lpm/rte_lpm.h | 93 +---
> > lib/librte_lpm/rte_lpm_sse.h | 143
> > +++
> > 5 files changed, 206 insertions(+), 100 deletions(-)
> > create mode 100644 app/test/test_xmmt_ops.h
> > create mode 100644 lib/librte_lpm/rte_lpm_sse.h
> >
> > diff --git a/app/test/test_lpm.c b/app/test/test_lpm.c
> > index 8b4ded9..59674f1 100644
> > --- a/app/test/test_lpm.c
> > +++ b/app/test/test_lpm.c
> > @@ -49,6 +49,7 @@
> >
> > #include "rte_lpm.h"
> > #include "test_lpm_routes.h"
> > +#include "test_xmmt_ops.h"
> >
> > #define TEST_LPM_ASSERT(cond) do {
> >\
> > if (!(cond)) {
> > \
> > @@ -308,7 +309,7 @@ test6(void)
> > int32_t
> > test7(void)
> > {
> > - __m128i ipx4;
> > + xmm_t ipx4;
> > uint16_t hop[4];
> > struct rte_lpm *lpm = NULL;
> > uint32_t ip = IPv4(0, 0, 0, 0);
> > @@ -324,7 +325,7 @@ test7(void)
> > status = rte_lpm_lookup(lpm, ip, _hop_return);
> > TEST_LPM_ASSERT((status == 0) && (next_hop_return == next_hop_add));
> >
> > - ipx4 = _mm_set_epi32(ip, ip + 0x100, ip - 0x100, ip);
> > + ipx4 = vect_set_epi32(ip, ip + 0x100, ip - 0x100, ip);
> > rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> > TEST_LPM_ASSERT(hop[0] == next_hop_add);
> > TEST_LPM_ASSERT(hop[1] == UINT16_MAX);
> > @@ -354,7 +355,7 @@ test7(void)
> > int32_t
> > test8(void)
> > {
> > - __m128i ipx4;
> > + xmm_t ipx4;
> > uint16_t hop[4];
> > struct rte_lpm *lpm = NULL;
> > uint32_t ip1 = IPv4(127, 255, 255, 255), ip2 = IPv4(128, 0, 0, 0);
> > @@ -380,7 +381,7 @@ test8(void)
> > TEST_LPM_ASSERT((status == 0) &&
> > (next_hop_return == next_hop_add));
> >
> > - ipx4 = _mm_set_epi32(ip2, ip1, ip2, ip1);
> > + ipx4 = vect_set_epi32(ip2, ip1, ip2, ip1);
> > rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> > TEST_LPM_ASSERT(hop[0] == UINT16_MAX);
> > TEST_LPM_ASSERT(hop[1] == next_hop_add);
> > @@ -408,7 +409,7 @@ test8(void)
> > status = rte_lpm_lookup(lpm, ip1, _hop_return);
> > TEST_LPM_ASSERT(status == -ENOENT);
> >
> > - ipx4 = _mm_set_epi32(ip1, ip1, ip2, ip2);
> > + ipx4 = vect_set_epi32(ip1, ip1, ip2, ip2);
> > rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> > if (depth != 1) {
> > TEST_LPM_ASSERT(hop[0] == next_hop_add);
> > @@ -850,7 +851,7 @@ test11(void)
> > int32_t
> > test12(void)
> > {
> > - __m128i ipx4;
> > + xmm_t ipx4;
> > uint16_t hop[4];
> > struct rte_lpm *lpm = NULL;
> > uint32_t ip, i;
> > @@ -872,7 +873,7 @@ test12(void)
> > TEST_LPM_ASSERT((status == 0) &&
> > (next_hop_return == next_hop_add));
> >
> > - ipx4 = _mm_set_epi32(ip, ip + 1, ip, ip - 1);
> > + ipx4 = vect_set_epi32(ip, ip + 1, ip, ip - 1);
> > rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
> > TEST_LPM_ASSERT(hop[0] == UINT16_MAX);
> > TEST_LPM_ASSERT(hop[1] == next_hop_add);
> > @@ -1289,10 +1290,10 @@ perf_test(void)
> > begin = rte_rdtsc();
> > for (j = 0; j < BATCH_SIZE; j += RTE_DIM(next_hops)) {
> > unsigned k;
> > - __m128i ipx4;
> > + xmm_t ipx4;
> >
> > - ipx4 = _mm_loadu_si128((__m128i *)(ip_batch + j));
> > - ipx4 = *(__m128i *)(ip_batch + j);
> > + ipx4 = vect_loadu_sil128((xmm_t *)(ip_batch + j));
> > + ipx4 = *(xmm_t *)(ip_batch + j);
> > rte_lpm_lookupx4(lpm, ipx4, next_hops, UINT16_MAX);
> > for (k = 0; k < RTE_DIM(next_hops); k++)
> > if (unlikely(next_hops[k] == UINT16_MAX))
> > diff --git a/app/test/test_xmmt_ops.h b/app/test/test_xmmt_ops.h
> > new file mode 100644
> > index 000..c055912
> > ---
[dpdk-dev] [PATCH v8 3/4] examples: add l3fwd-thread example in performance-thread
2015-12-07 04:46, Betts, Ian: > >>I had no time to check how it works. > >> I'm just surprised that you introduce a new config option. > >> +DIRS-$(CONFIG_RTE_PERFORMANCE_THREAD) += performance-thread > > I think this option should be removed. > > It is only to ensure that performance-thread example is built, along with all > other examples, > if you run "make" top level of examples folder. > Also to ensure it is only enabled for x86_64 linux. > > Is there is another way ? The config options must be avoided for libraries and not used for examples. You can use CONFIG_RTE_ARCH_X86_64.
[dpdk-dev] [PATCH v9 2/3] example: add user-space ethtool sample application
On 07/12/2015 02:29, Thomas Monjalon wrote: > 2015-11-20 15:34, Remy Horton: >> Signed-off-by: Remy Horton >> --- >> MAINTAINERS | 4 + >> examples/Makefile | 1 + >> examples/ethtool/Makefile | 48 ++ > > I'm really sorry, it doesn't compile in combined library mode. > We have to check it very shortly. > Looks like rte.extlib.mk not making the sub-directories that combined builds use. Whole patch needs rebasing anyway due to a merge conflict so will fix that as well.. ..Remy
[dpdk-dev] [i40e] Failed to init adminq?
Stephen Hemminger wrote on 12/04/2015 05:36:08 PM: > From: Stephen Hemminger > To: Eimear Morrissey/Ireland/IBM at IBMIE > Cc: dev at dpdk.org > Date: 12/04/2015 05:36 PM > Subject: Re: [dpdk-dev] [i40e] Failed to init adminq? > > On Fri, 4 Dec 2015 11:25:09 + > "Eimear Morrissey" wrote: > > > > > > > Hi, > > > > I'm having an issue with the i40e pmd failing to initialise a port. I've > > tried powercycling with the linux i40e driver removed and blacklisted as > > suggested here: http://dpdk.org/ml/archives/dev/2015-June/019132.html, but > > it's still persisting. It used to initialise without issues so I'm not sure > > what could have changed? I'm running it in the host at the moment but I > > have used that port pci passthrough'd to a guest also. > > > > Any suggestions as to what could be causing this? > > > > Thanks, > > Eimear > > > > EAL: PCI device :86:00.0 on NUMA socket 1 > > EAL: probe driver: 8086:1572 rte_i40e_pmd > > EAL: PCI memory mapped at 0x7f5d4000 > > EAL: PCI memory mapped at 0x7f5d4080 > > PMD: eth_i40e_dev_init(): Failed to init adminq: -54 > > EAL: Error - exiting with code: 1 > > Cause: Requested device :86:00.0 cannot be used > > > For me, it turned out to be a bug in earlier version > of a patch to support xen dom0. This happens if the memory zone > setup in i40e_allocate_dma_mem_d was not providing correct addresses. > > Anyway check if you have that correct. > > Also, updating firmware took more effort than expected. > 1. Need to run Intel's out of tree Linux driver for i40e > or the version in 4.4-rc1 or later. > 2. Need to use Linux driver (ie no DPDK) > 3. System needs access to internet to download firmware > > Overall, it is one of those "pray for bits" updates. > I'm using DPDK 2.1.0 - I'm not sure if that has the correct patch version or not? What's confusing is that it used to work but now it's completely stopped working & nothing (powercycling, binding to different drivers and back, even replacing the actual card) seems to affect it. I haven't upgraded the firmware on the card, but will try. -Eimear
[dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
Announce ABI change for struct rte_eth_conf. Signed-off-by: Jijiang Liu --- doc/guides/rel_notes/deprecation.rst |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 1c7ab01..f50f0c7 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -19,3 +19,7 @@ Deprecation Notices and table action handlers will be updated: the pipeline parameter will be added, the packets mask parameter will be either removed (for input port action handler) or made input-only. + +* ABI changes are planned for struct rte_eth_conf in order to support + tunneling packet configuration in unified tunneling API. The release 2.2 does not contain these ABI + changes, but release 2.3 will, and no backwards compatibility is planned. -- 1.7.7.6
[dpdk-dev] [PATCH v4] ip_pipeline: add flow actions pipeline
On 12/07/2015 03:17 AM, Thomas Monjalon wrote: > 2015-11-18 17:09, Fan Zhang: >> Flow actions pipeline is an extension of flow-classification pipeline. >> Some of the operations of flow classification pipeline such as traffic >> metering/marking(for e.g. Single Rate Three Color Marker (srTCM), Two >> Rate Three Color Marker trTCM)), policer can be performed separately in >> flow action pipeline to avoid excessive computational burden on the CPU >> core running the flow-classification pipeline. The Flow action pipeline >> implements various function such as traffic metering, policer, stats. >> Traffic mettering can configured as per the required context, for >> examples- per user, per traffic class or both. These contexts can be >> applied by specifying parameters in configuration file as shown below; >> >> [PIPELINE1] >> type = FLOW_ACTIONS >> core = 1 >> pktq_in = RXQ0.0 RXQ1.0 RXQ2.0 RXQ3.0 >> pktq_out = TXQ0.0 TXQ1.0 TXQ2.0 TXQ3.0 >> n_flows = 65536 >> n_meters_per_flow = 1 >> flow_id_offset = 158 >> ip_hdr_offset = 142 >> color_offset = 64 >> >> The entries of flow and dscp tables of flow actions pipeline can be >> modified through command-line interface. The commands to add or delete >> entries to the flow table, DSCP(differentiated services code point) >> table and for statistics collection, etc have been included. The key >> functions such as Traffic Metering/marking and policer functions have >> been implemented as flow-table action handler. >> >> Signed-off-by: Jasvinder Singh >> Signed-off-by: Fan Zhang >> Acked-by: Cristian Dumitrescu > > Applied, thanks > The patch tries to include pipeline_flow_actions.h which doesn't exist, making the ip_pipeline example unbuildable. Seems like a case of forgotten "git add" when creating the patch... - Panu -
[dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu > Sent: Monday, December 7, 2015 3:02 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf > > Announce ABI change for struct rte_eth_conf. > > Signed-off-by: Jijiang Liu Acked-by: Andrey Chilikin
[dpdk-dev] [PATCH v2] mk: pass EXTRA_CFLAGS to AUTO_CPUFLAGS to enable local modifications
On 12/04/2015 08:53 PM, Thomas Monjalon wrote: We have encountered a CPU where the AES-NI instruction set is disabled due to export restrictions. Since the build machine and target machine is different, using -native configs doesn't work, and on this CPU, the application refuses to run due to the AES CPU flags being amiss. The patch passes EXTRA_CFLAGS to the figure-out-cpu-flags helper, which allows us to add -mno-aes to the compile flags and resolve this problem. Signed-off-by: Simon Kagstrom >> >> Acked-by: Olivier Matz > > Applied, thanks > This causes some complications on Fedora/RHEL due to fairly complex interactions with -Werror, -Wall and -Wformat-security mixup between upstream- and distro default compiler flags. More specifically, when EXTRA_CFLAGS contains warning flag manipulation this patch can cause mismatch between other options that are okay elsewhere in dpdk make. A simple fix is to pass WERROR_FLAGS to AUTO_CPUFLAGS too to counter this, ie diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk index c6bb8de..28f203b 100644 --- a/mk/rte.cpuflags.mk +++ b/mk/rte.cpuflags.mk @@ -33,7 +33,7 @@ # used to set the RTE_CPUFLAG_* environment variables giving details # of what instruction sets the target cpu supports. -AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(EXTRA_CFLAGS) -dM -E - < /dev/null) +AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(WERROR_FLAGS) $(EXTRA_CFLAGS) -dM -E - < /dev/null) # adding flags to CPUFLAGS I can send an official patch if this seems acceptable. - Panu -
[dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
On Mon, Dec 07, 2015 at 03:03:24AM +0100, Thomas Monjalon wrote: > 2015-12-07 10:00, Yuanhan Liu: > > On Mon, Dec 07, 2015 at 12:07:28AM +0100, Thomas Monjalon wrote: > > > 2015-12-02 15:53, Panu Matilainen: > > > > This (and other changes in patch 2 breaks the librte_vhost ABI again, > > > > so > > > > you'd need to at least add a deprecation note to 2.2 to be able to do > > > > it > > > > in 2.3 at all according to the ABI policy. > > > > > > > > Perhaps a better option would be adding some padding to the structs now > > > > for 2.2 since the vhost ABI is broken there anyway. That would at least > > > > give a chance to keep it compatible from 2.2 to 2.3. > > > > > > Please could you point where the vhost ABI is broken in 2.2? > > > > Thomas, here are the changes to rte_virtio_net.h: > > > > > > $ git diff > > 381316f6a225139d22d39b5ab8d50c40607924ca..19d4d7ef2a216b5418d8edb5b004d1a58bba3cc1 > > \ > > -- lib/librte_vhost/rte_virtio_net.h > > [...] > > The problem is that the changes are not noticed in the release notes > and the LIBABIVER is still 1. Yeah, my bad. Firstly, I was not aware of it's an ABI change. Secondly, I was landed to this team in the middle of v2.2 release, so that I have limited experience of how those works in DPDK community. Anyway, it's my fault. I should have realized that in the first time. Should I send a patch to update LIBABIVER to 2 and update release note now? --yliu
[dpdk-dev] [PATCH 0/6] Add virtio support in arm/arm64
On Fri, Dec 04, 2015 at 11:05:13PM +0530, Santosh Shukla wrote: > This patch set add basic infrastrucure to run virtio-net-pci pmd driver for > arm64/arm. Tested on ThunderX platfrom. Verified for existing dpdk(s) test > applications like: > - ovs-dpdk-vhost-user: across the VM's, for the use-cases like guest2guest and > Host2Guest > - testpmd application: Tested for max virtio-net-pci interface currently > supported in kernel i.e. 31 interface. Hi Santosh, Here is a quick notice that I don't have time to review your patches this one or two weeks. Sorry for that. (Not quite sure Huawei has the bandwidth or not, btw) --yliu
[dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
On Mon, Dec 07, 2015 at 12:07:28AM +0100, Thomas Monjalon wrote:
> 2015-12-02 15:53, Panu Matilainen:
> > This (and other changes in patch 2 breaks the librte_vhost ABI again, so
> > you'd need to at least add a deprecation note to 2.2 to be able to do it
> > in 2.3 at all according to the ABI policy.
> >
> > Perhaps a better option would be adding some padding to the structs now
> > for 2.2 since the vhost ABI is broken there anyway. That would at least
> > give a chance to keep it compatible from 2.2 to 2.3.
>
> Please could you point where the vhost ABI is broken in 2.2?
Thomas, here are the changes to rte_virtio_net.h:
$ git diff
381316f6a225139d22d39b5ab8d50c40607924ca..19d4d7ef2a216b5418d8edb5b004d1a58bba3cc1
\
-- lib/librte_vhost/rte_virtio_net.h >
diff --git a/lib/librte_vhost/rte_virtio_net.h
b/lib/librte_vhost/rte_virtio_net.h
index e3a21e5..426a70d 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -89,6 +89,7 @@ struct vhost_virtqueue {
volatile uint16_t last_used_idx_res; /**< Used for multiple
devices reserving buffers. */
int callfd; /**< Used to notify the
guest (trigger interrupt). */
int kickfd; /**< Currently unused
as polling mode is enabled. */
+ int enabled;
struct buf_vector buf_vec[BUF_VECTOR_MAX];/**< for
scatter RX. */
} __rte_cache_aligned;
@@ -96,7 +97,6 @@ struct vhost_virtqueue {
* Device structure contains all configuration information relating to the
device.
*/
struct virtio_net {
- struct vhost_virtqueue *virtqueue[VIRTIO_QNUM];/**< Contains
all virtqueue information. */
struct virtio_memory*mem; /**< QEMU memory and memory
region information. */
uint64_tfeatures; /**< Negotiated feature set. */
uint64_tprotocol_features; /**< Negotiated
protocol feature set. */
@@ -104,7 +104,9 @@ struct virtio_net {
uint32_tflags; /**< Device flags. Only used to
check if device is running on data core. */
#define IF_NAME_SZ (PATH_MAX > IFNAMSIZ ? PATH_MAX : IFNAMSIZ)
charifname[IF_NAME_SZ]; /**< Name of the tap
device or socket path. */
+ uint32_tvirt_qp_nb; /**< number of queue pair we
have allocated */
void*priv; /**< private context */
+ struct vhost_virtqueue *virtqueue[VIRTIO_NET_CTRL_MQ_VQ_PAIRS_MAX];
/**< Contains all virtqueue information. */
} __rte_cache_aligned;
/**
@@ -131,7 +133,7 @@ struct virtio_memory {
};
/**
- * Device operations to add/remove device.
+ * Device and vring operations.
*
* Make sure to set VIRTIO_DEV_RUNNING to the device flags in new_device and
* remove it in destroy_device.
@@ -140,12 +142,18 @@ struct virtio_memory {
struct virtio_net_device_ops {
int (*new_device)(struct virtio_net *); /**< Add device. */
void (*destroy_device)(volatile struct virtio_net *); /**< Remove
device. */
+
+ int (*vring_state_changed)(struct virtio_net *dev, uint16_t queue_id,
int enable); /**< triggered when a vring is enabled or disabled */
};
static inline uint16_t __attribute__((always_inline))
rte_vring_available_entries(struct virtio_net *dev, uint16_t queue_id)
{
struct vhost_virtqueue *vq = dev->virtqueue[queue_id];
+
+ if (!vq->enabled)
+ return 0;
+
return *(volatile uint16_t *)>avail->idx - vq->last_used_idx_res;
}
--yliu
[dpdk-dev] [PATCH v4] ip_pipeline: add flow actions pipeline
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Monday, December 7, 2015 1:18 AM > To: Zhang, Roy Fan > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4] ip_pipeline: add flow actions pipeline > > 2015-11-18 17:09, Fan Zhang: > > Flow actions pipeline is an extension of flow-classification pipeline. > > Some of the operations of flow classification pipeline such as traffic > > > > Signed-off-by: Jasvinder Singh > > Signed-off-by: Fan Zhang > > Acked-by: Cristian Dumitrescu > > Applied, thanks Hi Thomas, This patch is not merged in the master. I don't see any source file. Regards, Jasvinder
[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
Hi, FYI I kind of "gave up" (not as bad as it sounds) and started looking into shipping it as individual libraries + linker script as well. To me it seemed what was more accepted in all the former discussions. It will surely cause more work for me in the short term, but I hope after the initial hill I have to climb to make it happen it will be not too much in future releases. So if "we" were the only one causing this to be deferred consider it for 2.2. That way distributions would become more similar which might help consumers of the DPDK libraries. In the worst case I can reverse apply it for 2.2 to get some more time to get it to work properly for us later on. Looking at the great changes to "make install" by Thomas being in 2.2 - getting the linker script "official" in 2.2 as well would also help to not get a major overhaul to packaging every version :-) have a great week, Christian Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Fri, Dec 4, 2015 at 6:19 PM, Thomas Monjalon wrote: > 2015-11-24 16:31, Panu Matilainen: > > The physically linked-together combined library has been an increasing > > source of problems, as was predicted when library and symbol versioning > > was introduced. Replace the complex and fragile construction with a > > simple linker script which achieves the same without all the problems, > > remove the related kludges from eg mlx drivers. > > > > Since creating the linker script is practically zero cost, remove the > > config option and just create it always. > > > > Based on a patch by Sergio Gonzales Monroy, linker script approach > > initially suggested by Neil Horman. > > > > Suggested-by: Sergio Gonzalez Monroy > > Suggested-by: Neil Horman > > Signed-off-by: Panu Matilainen > > As it is a big change and discussion is not totally closed, > it is deferred to release 2.3. > The fix from Ferruh could be sufficient for 2.2. >
[dpdk-dev] [PATCH 3/6] virtio: armv7/v8: Introdice api to emulate x86-style of PCI/ISA ioport access
On Fri, 4 Dec 2015 23:05:16 +0530 Santosh Shukla wrote: > +#if defined(RTE_ARCH_ARM64) > + uint64_tio_base; > +#else /* !ARM64 */ > uint32_tio_base; > +#endif Is there a typedef that could be used instead of having #ifdef clutter?
[dpdk-dev] [PATCH 6/6] virtio: arm/arm64: memory mapped IO support in pmd driver
On Fri, 4 Dec 2015 23:05:19 +0530 Santosh Shukla wrote: > > +#ifdef RTE_EXEC_ENV_LINUXAPP > +/* start address of first pci_iobar slot (user-space virtual-addres) */ > +void *ioport_map; > +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64) > + > +#include > +#define DEV_NAME "/dev/igb_ioport" > + > +/* Keeping pci_ioport_size = 4k. > + * So maximum mmaped pci_iobar supported = > + * (ioport_size/pci_dev->mem_resource[0].len) > + * > + * note: kernel could allow maximum 32 virtio-net-pci interface, that mean > + * maximum 32 PCI_IOBAR(s) where each PCI_IOBAR_LEN=0x20, so > virtio_map_ioport() > + * func by theory gonna support 4k/0x20 ==> 128 PCI_IOBAR(s), more than > + * max-virtio-net-pci interface. > + */ > +#define PAGE_SIZE4096 > +#define PCI_IOPORT_SIZE PAGE_SIZE > +#define PCI_IOPORT_MAX 128 /* 4k / 0x20 */ > + > +int ioport_map_cnt; > +#endif /* ARM, ARM64 */ > +#endif /* RTE_EXEC_ENV_LINUXAPP */ These variables should be static. Also, it is should be possible to extract the I/O bar stuff in a generic way through sysfs and not depend on a character device. The long term goal for DPDK acceptance is to eliminate (or at least reduce to a minumum) any requirement for special kernel drivers.
[dpdk-dev] [PATCH] examples/dpdk_qat: Fix RX queue start number to the one just received the packets
On 07/12/15 01:32, Thomas Monjalon wrote:
> 2015-09-29 19:07, Zhe Tao:
>> Every time we started to receive the packets, the start queue number
>> should be the one that just received the packets, should not start from zero!
>>
> [...]
>> -for (i = 0; i < qconf->n_rx_queue; i++) {
>> +for (i = qconf->rx_curr_queue; i < qconf->n_rx_queue; i++) {
>
> Anyone to confirm?
>
I'll have a look at this this morning Thomas.
[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
Hi Christian, You can count on me to help testing DPDK for Ubuntu, I have plans for it! I have some experience with Debian packaging too... I'm currently maintaining few Ubuntu PPAs, for fun...=) Also, I have hardware available, with 10G, 40G and 100G NIC cards and traffic generators. I would love to help! Specially when with DPDK on Xen (plans for in on PVM, HVM, XenServer and Amazon EC2). Just a curiosity, I'm the designer/maintainer of "Xen LiveCD v2.0" and I would like to build a new version of it, that will be based on Xenial with DPDK. http://wiki.xenproject.org/wiki/Live_CD_(Xen_3.2_%2B_Debian_5.0) https://github.com/tmartinx/xenlivecd Hope to see DPDK compiling with Xen on 32-bit (it is broken now), so we can enable it on Ubuntu! Cheers! Thiago On 7 December 2015 at 06:27, Christian Ehrhardt wrote: > Hi, > FYI I kind of "gave up" (not as bad as it sounds) and started looking into > shipping it as individual libraries + linker script as well. > To me it seemed what was more accepted in all the former discussions. > > It will surely cause more work for me in the short term, but I hope after > the initial hill I have to climb to make it happen it will be not too much > in future releases. > > So if "we" were the only one causing this to be deferred consider it for > 2.2. > That way distributions would become more similar which might help consumers > of the DPDK libraries. > In the worst case I can reverse apply it for 2.2 to get some more time to > get it to work properly for us later on. > > Looking at the great changes to "make install" by Thomas being in 2.2 - > getting the linker script "official" in 2.2 as well would also help to not > get a major overhaul to packaging every version :-) > > have a great week, > Christian > > > > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd > > On Fri, Dec 4, 2015 at 6:19 PM, Thomas Monjalon > wrote: > >> 2015-11-24 16:31, Panu Matilainen: >> > The physically linked-together combined library has been an increasing >> > source of problems, as was predicted when library and symbol versioning >> > was introduced. Replace the complex and fragile construction with a >> > simple linker script which achieves the same without all the problems, >> > remove the related kludges from eg mlx drivers. >> > >> > Since creating the linker script is practically zero cost, remove the >> > config option and just create it always. >> > >> > Based on a patch by Sergio Gonzales Monroy, linker script approach >> > initially suggested by Neil Horman. >> > >> > Suggested-by: Sergio Gonzalez Monroy >> > Suggested-by: Neil Horman >> > Signed-off-by: Panu Matilainen >> >> As it is a big change and discussion is not totally closed, >> it is deferred to release 2.3. >> The fix from Ferruh could be sufficient for 2.2. >>
[dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
On 12/07/2015 01:07 AM, Thomas Monjalon wrote: > 2015-12-02 15:53, Panu Matilainen: >> This (and other changes in patch 2 breaks the librte_vhost ABI again, so >> you'd need to at least add a deprecation note to 2.2 to be able to do it >> in 2.3 at all according to the ABI policy. >> >> Perhaps a better option would be adding some padding to the structs now >> for 2.2 since the vhost ABI is broken there anyway. That would at least >> give a chance to keep it compatible from 2.2 to 2.3. > > Please could you point where the vhost ABI is broken in 2.2? > The vhost ABI break was announced for DPDK 2.2 in commit 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d: > commit 3c848bd7b1c6f4f681b833322a748fdefbb5fb2d > Author: Ouyang Changchun > Date: Tue Jun 16 09:38:43 2015 +0800 > > doc: announce ABI changes for vhost-user multiple queues > > It announces the planned ABI changes for vhost-user multiple > queues feature on v2.2. > > Signed-off-by: Changchun Ouyang > Acked-by: Neil Horman So the ABI process was properly followed, except for actually bumping LIBABIVER. Bumping LIBABIVER is mentioned in doc/guides/contributing/versioning.rst but it doesn't specify *when* this should be done, eg should the first patch breaking the ABI bump it or should it done be shortly before the next stable release, or something else. As it is, it seems a bit too easy to simply forget. - Panu -
[dpdk-dev] [PATCH 1/1] kni: Fix compilation problems on RHEL 7.2.
RHEL 7.2 contains additional backports from newer upstream kernels. Add RHEL_RELEASE_CODE logic for RHEL_RELEASE_VERSION(7,2) to pick up the changes to kernel functions. Signed-off-by: Lee Roberts --- lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c | 4 ++-- lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 15 --- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c index b330b20..9d4fa59 100644 --- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c +++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c @@ -2274,7 +2274,7 @@ static int igb_ndo_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq, else mode = BRIDGE_MODE_VEPA; -#ifdef HAVE_NDO_FDB_ADD_VID +#ifdef HAVE_NDO_DFLT_BRIDGE_ADD_MASK #ifdef HAVE_NDO_BRIDGE_GETLINK_NLFLAGS #ifdef HAVE_NDO_BRIDGE_GETLINK_FILTER_MASK_VLAN_FILL return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode, 0, 0, @@ -2287,7 +2287,7 @@ static int igb_ndo_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq, #endif /* HAVE_NDO_BRIDGE_GETLINK_NLFLAGS */ #else return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode); -#endif /* HAVE_NDO_FDB_ADD_VID */ +#endif /* HAVE_NDO_DFLT_BRIDGE_ADD_MASK */ } #endif /* HAVE_BRIDGE_ATTRIBS */ #endif /* NTF_SELF */ diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h index 68a3b9f..e2cf71e 100644 --- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h +++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h @@ -3881,20 +3881,29 @@ skb_set_hash(struct sk_buff *skb, __u32 hash, __always_unused int type) #endif /* < RHEL7 */ #endif /* < 3.14.0 */ -#if ( LINUX_VERSION_CODE >= KERNEL_VERSION(3,16,0) ) +#if (( LINUX_VERSION_CODE >= KERNEL_VERSION(3,16,0) ) \ +|| ( RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,2) )) +#undef SET_ETHTOOL_OPS #define SET_ETHTOOL_OPS(netdev, ops) ((netdev)->ethtool_ops = (ops)) #define HAVE_VF_MIN_MAX_TXRATE 1 #endif /* >= 3.16.0 */ -#if ( LINUX_VERSION_CODE >= KERNEL_VERSION(3,19,0) ) +#if (( LINUX_VERSION_CODE >= KERNEL_VERSION(3,19,0) ) \ +|| ( RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,2) )) +#define HAVE_NDO_DFLT_BRIDGE_ADD_MASK +#if (!( RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,2) )) #define HAVE_NDO_FDB_ADD_VID +#endif /* !RHEL 7.2 */ #endif /* >= 3.19.0 */ -#if ( LINUX_VERSION_CODE >= KERNEL_VERSION(4,0,0) ) +#if (( LINUX_VERSION_CODE >= KERNEL_VERSION(4,0,0) ) \ +|| ( RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,2) )) /* vlan_tx_xx functions got renamed to skb_vlan */ #define vlan_tx_tag_get skb_vlan_tag_get #define vlan_tx_tag_present skb_vlan_tag_present +#if (!( RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(7,2) )) #define HAVE_NDO_BRIDGE_SET_DEL_LINK_FLAGS +#endif /* !RHEL 7.2 */ #endif /* 4.0.0 */ #if ( LINUX_VERSION_CODE >= KERNEL_VERSION(4,1,0) ) -- 1.9.1
[dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, December 07, 2015 11:40 AM > To: Liu, Jijiang > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct > rte_eth_conf > > 2015-12-07 03:30, Liu, Jijiang: > > Hi Thomas, > > > > > -Original Message- > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > Sent: Monday, December 07, 2015 11:17 AM > > > To: Liu, Jijiang > > > Cc: dev at dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct > > > rte_eth_conf > > > > > > 2015-12-07 11:01, Jijiang Liu: > > > > +* ABI changes are planned for struct rte_eth_conf in order to > > > > +support > > > > + tunneling packet configuration in unified tunneling API. The > > > > +release 2.2 > > > does not contain these ABI > > > > + changes, but release 2.3 will, and no backwards compatibility is > planned. > > > > > > Please, more details would be appreciated. > > > We need to decide whether an ABI deprecation is the right choice. > > > > * ABI changes are planned for struct rte_eth_conf in order to support > > tunneling packet configuration in unified tunneling APIs, which is the > rte_eth_dev_tunnel_configure > > (uint8_t port_id, uint16_t rx_q, uint16_t tx_q, rte_eth_tunnel_conf * > tunnel_conf) API is planned to add. > > and the 'tunnel_conf' shloud be stored in global 'rte_eth_conf'. > > The release 2.2 does not contain these ABI change, but release 2.3 will, > and no backwards compatibility is planned. > > > > Is it enough clear? > > No, I think we need an explanation in the commit message of what is the > purpose of rte_eth_dev_tunnel_configure() and tunnel_conf. Ok, will do. > Ideally, an RFC patch would help. I'm working on RFC patch, but it probably will miss merge timeslot of this release.
[dpdk-dev] [PATCH] bnx2x: set Ethernet address type during transmit for VF's
On Sun, 2015-12-06 at 23:34 +, Harish Patil wrote:
> >
> >The original was always setting unicast. While here, clean up some
> >other references that also point into the Ethernet header.
> >
> >Signed-off-by: Chas Williams <3chas3 at gmail.com>
> >---
> > drivers/net/bnx2x/bnx2x.c | 23 +++
> > drivers/net/bnx2x/ecore_hsi.h | 5 +++--
> > 2 files changed, 18 insertions(+), 10 deletions(-)
> >
> >diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
> >index 76444eb..294711f 100644
> >--- a/drivers/net/bnx2x/bnx2x.c
> >+++ b/drivers/net/bnx2x/bnx2x.c
> >@@ -2177,25 +2177,32 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq,
> >struct rte_mbuf **m_head, int m_p
> > bd_prod = NEXT_TX_BD(bd_prod);
> > if (IS_VF(sc)) {
> > struct eth_tx_parse_bd_e2 *tx_parse_bd;
> >- uint8_t *data = rte_pktmbuf_mtod(m0, uint8_t *);
> >+ const struct ether_hdr *eh = rte_pktmbuf_mtod(m0,
> >struct ether_hdr *);
> >+ uint8_t mac_type = UNICAST_ADDRESS;
> >
> > tx_parse_bd =
> > >tx_ring[TX_BD(bd_prod, txq)].parse_bd_e2;
> >+ if (is_multicast_ether_addr(>d_addr)) {
>
> Minor comment. unlikely() may be used here to keep it consistent with base
> driver.
It wasn't clear to me that this code path is all that unlikely().
> >+ if (is_broadcast_ether_addr(>d_addr))
> >+ mac_type = BROADCAST_ADDRESS;
> >+ else
> >+ mac_type = MULTICAST_ADDRESS;
> >+ }
[dpdk-dev] [PATCH 0/2] Clear rx_mbuf_alloc_failed counter on rte_eth_stats_reset
2015-11-27 13:31, 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 Acked-by: Thomas Monjalon Applied, thanks
[dpdk-dev] [PATCH v8 3/4] examples: add l3fwd-thread example in performance-thread
-Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Monday, December 7, 2015 2:36 AM To: Betts, Ian Cc: dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v8 3/4] examples: add l3fwd-thread example in performance-thread > Hi, >>I had no time to check how it works. >> I'm just surprised that you introduce a new config option. >> +DIRS-$(CONFIG_RTE_PERFORMANCE_THREAD) += performance-thread > I think this option should be removed. It is only to ensure that performance-thread example is built, along with all other examples, if you run "make" top level of examples folder. Also to ensure it is only enabled for x86_64 linux. Is there is another way ?
[dpdk-dev] [PATCH] doc: Add missing new line before code block
> > The patch adds missing new line to "Managing ABI updates" section. > > > > Signed-off-by: Tetsuya Mukawa > > Acked-by: John McNamara Applied, thanks
[dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
2015-12-07 03:30, Liu, Jijiang: > Hi Thomas, > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Monday, December 07, 2015 11:17 AM > > To: Liu, Jijiang > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for struct > > rte_eth_conf > > > > 2015-12-07 11:01, Jijiang Liu: > > > +* ABI changes are planned for struct rte_eth_conf in order to support > > > + tunneling packet configuration in unified tunneling API. The release > > > 2.2 > > does not contain these ABI > > > + changes, but release 2.3 will, and no backwards compatibility is > > > planned. > > > > Please, more details would be appreciated. > > We need to decide whether an ABI deprecation is the right choice. > > * ABI changes are planned for struct rte_eth_conf in order to support > tunneling packet configuration in unified tunneling APIs, which is the > rte_eth_dev_tunnel_configure > (uint8_t port_id, uint16_t rx_q, uint16_t tx_q, rte_eth_tunnel_conf * > tunnel_conf) API is planned to add. > and the 'tunnel_conf' shloud be stored in global 'rte_eth_conf'. > The release 2.2 does not contain these ABI change, but release 2.3 will, > and no backwards compatibility is planned. > > Is it enough clear? No, I think we need an explanation in the commit message of what is the purpose of rte_eth_dev_tunnel_configure() and tunnel_conf. Ideally, an RFC patch would help.
[dpdk-dev] [PATCH] doc: fix examples in netmap compatibility docs
> > Fix the examples in the netmap compatibility sample application > > docs which referred to the packet_reordering application. > > > > Also fix some minor rst formatting issues. > > > > Reported-by: Qian Xu > > Signed-off-by: John McNamara > > Acked-by: Pablo de Lara Applied, thanks
[dpdk-dev] [PATCH v2] doc: fix repeated typo in sample app docs
> > Fix repeated typo in the "Compiling the Application" section of > > almost all of the sample app docs. > > > > This generally gets copied into new sample app guides. > > > > Signed-off-by: John McNamara > > Acked-by: Pablo de Lara Applied, thanks
[dpdk-dev] [PATCH] remove blank lines at end-of-file
2015-12-03 09:53, Bruce Richardson: > On Wed, Dec 02, 2015 at 12:06:12PM -0800, Stephen Hemminger wrote: > > This is one of those trivial things git and other tools complain > > about. > > > > Signed-off-by: Stephen Hemminger > Acked-by: Bruce Richardson Applied, thanks
[dpdk-dev] [PATCH] remove double semicolons
2015-12-03 09:53, Bruce Richardson: > On Wed, Dec 02, 2015 at 01:02:32PM -0800, Stephen Hemminger wrote: > > Trivial cleanup > > > > Signed-off-by: Stephen Hemminger > Acked-by: Bruce Richardson Applied, thanks
[dpdk-dev] [PATCH] librte_power: channel_commands: Remove duplicate definition
> > The CHANNEL_CMDS_MAX_VM_CHANNELS is duplicated in the channel_commands
> > header file. This commit removes that duplication.
> >
> > fixes 210c383e247b5335cd95223fac1c0880ebbd5c96 ("power: packet format for
> > ...")
> >
> > Signed-off-by: Aaron Conole
>
> Acked-by: Bruce Richardson
Applied, thanks
[dpdk-dev] [PATCH] doc: announce ABI change for struct rte_eth_conf
2015-12-07 11:01, Jijiang Liu: > +* ABI changes are planned for struct rte_eth_conf in order to support > + tunneling packet configuration in unified tunneling API. The release 2.2 > does not contain these ABI > + changes, but release 2.3 will, and no backwards compatibility is planned. Please, more details would be appreciated. We need to decide whether an ABI deprecation is the right choice.
[dpdk-dev] [PATCH] app/testpmd: add 'show (rxq|txq)' command description into UG and cmdline help
> > Signed-off-by: Konstantin Ananyev
>
> Acked-by: Pablo de Lara
Fixes: ab3257e13dc4 ("app/testpmd: add command to display queue info")
Applied, thanks
[dpdk-dev] [PATCH] app/test: fix of returning wrong value
2015-12-03 11:22, Helin Zhang:
> In the KNI unit test, if all test cases passed, it should
> return with 0. This patch fixes the issue of returning
> wrong value.
>
> Fixes: fc27caaafd4b ("kni: remove deprecated functions")
>
> Signed-off-by: Helin Zhang
Applied, thanks
[dpdk-dev] [PATCH 1/1] table_test: renamed test_table_ACL to lowercase
> > Renamed function name to comply with coding standard. > > > > Signed-off-by: Maciej Gajdzica > > Acked-by: Pablo de Lara Applied, thanks
[dpdk-dev] [PATCH v4 0/2] ring pmd autotest
2015-11-28 11:01, Bernard Iremonger: > Fix failures in the ring_pmd_autotest program. > Correct errors in the ring PMD documentation. > > Changes in v4: > rebase to latest code. > update commit messages. > add Fixes: line to commit messages. > > Changes in v3: > rebase to latest code. > revise 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 Applied, thanks
[dpdk-dev] [PATCH 1/4] vhost: handle VHOST_USER_SET_LOG_BASE request
2015-12-07 10:18, Yuanhan Liu: > On Mon, Dec 07, 2015 at 03:03:24AM +0100, Thomas Monjalon wrote: > > 2015-12-07 10:00, Yuanhan Liu: > > > On Mon, Dec 07, 2015 at 12:07:28AM +0100, Thomas Monjalon wrote: > > > > 2015-12-02 15:53, Panu Matilainen: > > > > > This (and other changes in patch 2 breaks the librte_vhost ABI again, > > > > > so > > > > > you'd need to at least add a deprecation note to 2.2 to be able to do > > > > > it > > > > > in 2.3 at all according to the ABI policy. > > > > > > > > > > Perhaps a better option would be adding some padding to the structs > > > > > now > > > > > for 2.2 since the vhost ABI is broken there anyway. That would at > > > > > least > > > > > give a chance to keep it compatible from 2.2 to 2.3. > > > > > > > > Please could you point where the vhost ABI is broken in 2.2? > > > > > > Thomas, here are the changes to rte_virtio_net.h: > > > > > > > > > $ git diff > > > 381316f6a225139d22d39b5ab8d50c40607924ca..19d4d7ef2a216b5418d8edb5b004d1a58bba3cc1 > > > \ > > > -- lib/librte_vhost/rte_virtio_net.h > > > [...] > > > > The problem is that the changes are not noticed in the release notes > > and the LIBABIVER is still 1. > > Yeah, my bad. Firstly, I was not aware of it's an ABI change. Secondly, > I was landed to this team in the middle of v2.2 release, so that I have > limited experience of how those works in DPDK community. > > Anyway, it's my fault. I should have realized that in the first time. No it's not your fault, and it does not matter who is responsible. > Should I send a patch to update LIBABIVER to 2 and update release note > now? Yes today or tomorrow please.
[dpdk-dev] [PATCH] app/test: fix memory_autotest integer overflow/wraparound
> > memory_autotest loops infinitely when at least one the memsegs > > is bigger than 4GB. > > > > The issue is the result of an integer overflow/wraparound of > > the offset variable. > > > > Fix it by using the correct type (size_t). > > > > Signed-off-by: Sergio Gonzalez Monroy > > > > Acked-by: Pablo de Lara Applied, thanks
[dpdk-dev] [PATCH] test: fix crash in pmd_perf_test
2015-11-23 11:45, David Hunt: > Fix crash in pmd_perf_test autotest (div by 0) when no packets received > Also fixes the fact that the test passes even if exec_burst fails > > To repeat the issue: > The system must be incorrectly set up so that all packets will be lost, > i.e. no loopback cable, etc. This is an edge case, but still the test > should not crash or pass when failing. > run the test app > RTE>> set_rxtx_sc poll_before_xmit > RTE>> pmd_perf_autotest > --snip-- > > Generate 4096 packets @socket 1 > > start to receive total expect 4096 > > 4096 packets lost, IDLE 1 times > > Floating point exception (core dumped) > > Signed-off-by: David Hunt Applied, thanks
[dpdk-dev] [PATCH 0/2] fix performance/cache resource issues with 128-byte cache line targets
2015-12-07 12:56, Jerin Jacob: > On Sun, Dec 06, 2015 at 05:30:50PM +0100, Thomas Monjalon wrote: > > 2015-12-06 21:29, Jerin Jacob: > > > This patchset fixes performance/cache resource issues with 128-byte cache > > > line targets > > > found in mbuf and bitmap DPDK libraries > > > > > > Currently, we have two DPDK targets(ThunderX and ppc_64) which are based > > > on > > > 128-bytes cache line size target. > > > > When introducing IBM Power8, we failed to clean the cache line size > > definition. > > I promised to not forget this issue in this thread with Neil: > > http://dpdk.org/ml/archives/dev/2014-December/009439.html > > > > It is defined in > > config/defconfig_* > > mk/machine/*/rte.vars.mk > > mk/arch/*/rte.vars.mk > > rte_memory.h > > rte_kni_common.h > > > > It should be defined only in the config files. > > When we will introduce a configure script, we should be able to detect it. > > > > Please Jerin, as ThunderX maintainer, may you help to fix this old mess? > > Yes Thomas, I will takeup this issue when we will have configure script. I thought we could start setting the value in only one place. The detection in configure script would be another step. > apart from that, content of the this patch will be still valid > as the fix going to be generating cache line define from the config file.
[dpdk-dev] [PATCH v8 2/4] examples: add lthread subsystem forperformance-thread
Please add the new directory in the MAINTAINERS file. Thanks
[dpdk-dev] [PATCH v8 3/4] examples: add l3fwd-thread example in performance-thread
Hi, I had no time to check how it works. I'm just surprised that you introduce a new config option. 2015-12-04 10:34, Ian Betts: > --- a/config/defconfig_x86_64-native-linuxapp-gcc > +++ b/config/defconfig_x86_64-native-linuxapp-gcc > @@ -40,3 +40,5 @@ CONFIG_RTE_ARCH_64=y > > CONFIG_RTE_TOOLCHAIN="gcc" > CONFIG_RTE_TOOLCHAIN_GCC=y > + > +CONFIG_RTE_PERFORMANCE_THREAD=y > diff --git a/config/defconfig_x86_64-native-linuxapp-icc > b/config/defconfig_x86_64-native-linuxapp-icc > index 71d1e28..4c8e6ac 100644 > --- a/config/defconfig_x86_64-native-linuxapp-icc > +++ b/config/defconfig_x86_64-native-linuxapp-icc > @@ -40,3 +40,5 @@ CONFIG_RTE_ARCH_64=y > > CONFIG_RTE_TOOLCHAIN="icc" > CONFIG_RTE_TOOLCHAIN_ICC=y > + > +CONFIG_RTE_PERFORMANCE_THREAD=y > diff --git a/examples/Makefile b/examples/Makefile > index 5dd2c53..c7e786d 100644 > --- a/examples/Makefile > +++ b/examples/Makefile > @@ -77,5 +77,6 @@ DIRS-y += vmdq > DIRS-y += vmdq_dcb > DIRS-$(CONFIG_RTE_LIBRTE_POWER) += vm_power_manager > DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += l2fwd-crypto > +DIRS-$(CONFIG_RTE_PERFORMANCE_THREAD) += performance-thread I think this option should be removed.
[dpdk-dev] [PATCH v9 2/3] example: add user-space ethtool sample application
2015-11-20 15:34, Remy Horton: > Further enhancements to the userspace ethtool implementation that was > submitted in 2.1 and packaged as a self-contained sample application. > Implements an rte_ethtool shim layer based on rte_ethdev API, along > with a command prompt driven demonstration application. > > Signed-off-by: Remy Horton > --- > MAINTAINERS | 4 + > examples/Makefile | 1 + > examples/ethtool/Makefile | 48 ++ I'm really sorry, it doesn't compile in combined library mode. We have to check it very shortly.
