Re: [dpdk-dev] Issue->Dpdk for arm cortex-a15 compilation
I assume after git clone https://github.com/RehiveTech/buildroot I need to git checkout dpdk-support-v5 I get legacy error on running make root@xav101000739:~/Downloads/dpdk/newbuildroot/buildroot# *make * *Makefile.legacy:12: *** "You have legacy configuration in your .config! Please check your configuration.". Stop.* Thanks On Tue, May 16, 2017 at 5:58 PM, Jan Viktorin wrote: > On Tue, 16 May 2017 17:25:20 +0530 > Jimmy Carter wrote: > > > Hi All > > > > Attached is the complete env variables file > > I have added RTE_KERNELDIR too > > Also I am now using gnu-eabi version 5.4.0 > > [arm-openwrt-linux-muslgnueabi-gcc (LEDE GCC 5.4.0 r3909-6411a12) 5.4.0] > > But I am still getting the same error > > > > Currently I am not using buildroot > > Is there any step by step available guide for cross compiling dpdk using > > buildroot for target arm cortex-a15 using some external toolchain. > > I found this http://dpdk.org/ml/archives/announce/2015-October/66. > html > > This short tutorial points to some older version of the Buildroot > support. That was before the ARM support has been merged into DPDK. > > I've just pushed the branch dpdk-support-v5 (d25ddaadf2) into > the RehiveTech repository. It contains the latest patch sent to the > Buildroot mailing list [1] and some more. By the way, it cleanly > applies to the latest Buildroot master as well. > > This branch assumes DPDK 16.04 which is quite old but if you drop the > 0001-mk-do-not-enforce-any-specific-ARM-ABI.patch, it might work for newer > DPDK as well. > > Steps: > > $ git clone https://github.com/RehiveTech/buildroot > $ cd buildroot > $ make qemu_arm_vexpress_defconfig > $ make menuconfig > > * set libc library to glibc > * enable DPDK in Target packages/Libraries/Networking/DPDK > > $ make linux-menuconfig > > * enable UIO, PCI and MSI-X (if applicable) > > $ make > > I didn't test it myself recently but I belive that it should work well. > Instead of qemu_arm_vexpress_defconfig, you should select your target > board, if applicable. > > I hope, it would help you. > > Regards > Jan > > [1] https://patchwork.ozlabs.org/patch/611383/ > > > > > > > Please advise > > > > > > > > Thanks > > > > On Tue, May 16, 2017 at 5:14 PM, Neil Horman > wrote: > > > > > On Tue, May 16, 2017 at 12:51:40PM +0200, Jan Viktorin wrote: > > > > Hello Jimmy, > > > > > > > > On Tue, 16 May 2017 15:38:22 +0530 > > > > Jimmy Carter wrote: > > > > > > > > > Hi All > > > > > > > > > > I am using dpdk16.11.1 and want to use openwrt external toolchain > so > > > that I > > > > > can cross compile for arm cortex 15 > > > > > neon.(arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi) > > > > > > > > I've never built DPDK with musl-eabi. I don't think that your issue > is > > > > related but just note that my builds have always been done with > gnueabi. > > > > > > > > > My target board is Tp link archer C2600. > > > > > I am have assigned these env variables but still getting > compilation > > > error > > > > > > > > > > export > > > > > STAGING_DIR=/home/xav-101000739/ovslede/source/ > > > staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi > > > > > export > > > > > PATH=$PATH:/home/xav-101000739/ovslede/source/ > > > staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4. > 0_musl_eabi/bin > > > > > > > > > > > > > > > export CROSS=arm-openwrt-linux- > > > > > export DPDK_TARGET=arm-armv7a-linuxapp-gcc > > > > > export DPDK_DIR=$PWD > > > > > export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET > > > > > export > > > > > CFLAGS+=-I/home/xav-101000739/ovslede/source/staging_dir/ > > > toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi > > > > > export RTE_SDK=$PWD > > > > > export RTE_TARGET=arm-armv7a-linuxapp-gcc > > > > > export DPDK_BUILD_DIR=arm-armv7a-linuxapp-gcc > > > > > > > > > > > > > There is a patch to Buildroot that can help you with the setup. See: > > > > > > > > https://patchwork.ozlabs.org/patch/611383/ > > > > > > > > > > > > > > Error:Attached file > > > > > > > > Your build fails on > > > > > > > > eal_memory.c:92: > > > > /home/xav-101000739/Downloads/dpdk/dpdk-stable-16.11.1/ > > > build/include/rte_lcore.h:56:10: error: unknown type name 'cpu_set_t' > > > > typedef cpu_set_t rte_cpuset_t; > > > > > > > > This looks like there is some issue with Linux Kernel headers. > > > > > > > > lib/librte_eal/common/include/rte_lcore.h: > > > > > > > > 53 #if defined(__linux__) > > > > 54 typedef cpu_set_t rte_cpuset_t; > > > > 55 #elif defined(__FreeBSD__) > > > > 56 #include > > > > 57 typedef cpuset_t rte_cpuset_t; > > > > 58 #endif > > > > > > > > Probably, you should set the RTE_KERNELDIR properly. > > > > > > > I don't think so. cpu_set_t is most recently defined in > > > /usr/include/bits/shced.h, which is a glibc header. What version of > glibc > > > are > > > you building with? > > > > > > Neil > > > > > > > > > > > > > Please advise > > > > > Does dpdk have support for openwrt (arm cortex a15) > > > > > > > >
[dpdk-dev] [PATCH v2 0/2] examples/performance-thread: add arm64 support
This series of patches adds the arm64 support for performance-thread app. Patch 1 moves some x86 specific code to architecture dependent directory Patch 2 adds the necessary arm64 support for lthread. v2: * Split the patch into separate patches, one for code reorg and another for adding arm64 support. Ashwin Sekhar T K (2): examples/performance-thread: reorganise arch dependent code examples/performance-thread: add arm64 support examples/performance-thread/Makefile | 4 +- .../performance-thread/common/arch/arm64/ctx.c | 99 ++ .../performance-thread/common/arch/arm64/ctx.h | 95 ++ .../performance-thread/common/arch/arm64/stack.h | 111 + .../performance-thread/common/arch/x86/stack.h | 66 examples/performance-thread/common/common.mk | 10 +- examples/performance-thread/common/lthread.c | 11 +- examples/performance-thread/l3fwd-thread/main.c| 2 +- 8 files changed, 384 insertions(+), 14 deletions(-) create mode 100644 examples/performance-thread/common/arch/arm64/ctx.c create mode 100644 examples/performance-thread/common/arch/arm64/ctx.h create mode 100644 examples/performance-thread/common/arch/arm64/stack.h create mode 100644 examples/performance-thread/common/arch/x86/stack.h -- 2.12.2
[dpdk-dev] [PATCH v2 1/2] examples/performance-thread: reorganise arch dependent code
Moved the architecture dependent stack set code to architecture
specific directory.
Signed-off-by: Ashwin Sekhar T K
---
.../performance-thread/common/arch/x86/stack.h | 66 ++
examples/performance-thread/common/common.mk | 8 ++-
examples/performance-thread/common/lthread.c | 11 +---
3 files changed, 74 insertions(+), 11 deletions(-)
create mode 100644 examples/performance-thread/common/arch/x86/stack.h
diff --git a/examples/performance-thread/common/arch/x86/stack.h
b/examples/performance-thread/common/arch/x86/stack.h
new file mode 100644
index 0..80c06bf1c
--- /dev/null
+++ b/examples/performance-thread/common/arch/x86/stack.h
@@ -0,0 +1,66 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Intel Corporation. All rights reserved.
+ * Copyright(c) Cavium networks Ltd. 2017.
+ * 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.
+ */
+
+
+#ifndef STACK_H
+#define STACK_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "lthread_int.h"
+
+/*
+ * Sets up the initial stack for the lthread.
+ */
+static inline void
+arch_set_stack(struct lthread *lt, void *func)
+{
+ char *stack_top = (char *)(lt->stack) + lt->stack_size;
+ void **s = (void **)stack_top;
+
+ /* set initial context */
+ s[-3] = NULL;
+ s[-2] = (void *)lt;
+ lt->ctx.rsp = (void *)(stack_top - (4 * sizeof(void *)));
+ lt->ctx.rbp = (void *)(stack_top - (3 * sizeof(void *)));
+ lt->ctx.rip = func;
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* STACK_H_ */
diff --git a/examples/performance-thread/common/common.mk
b/examples/performance-thread/common/common.mk
index f6cab7718..532dbf61d 100644
--- a/examples/performance-thread/common/common.mk
+++ b/examples/performance-thread/common/common.mk
@@ -37,8 +37,12 @@
MKFILE_PATH=$(abspath $(dir $(lastword $(MAKEFILE_LIST
-VPATH := $(MKFILE_PATH) $(MKFILE_PATH)/arch/x86
+ifeq ($(CONFIG_RTE_ARCH_X86_64),y)
+ARCH_PATH += $(MKFILE_PATH)/arch/x86
+endif
+
+VPATH := $(MKFILE_PATH) $(ARCH_PATH)
SRCS-y += lthread.c lthread_sched.c lthread_cond.c lthread_tls.c
lthread_mutex.c lthread_diag.c ctx.c
-INCLUDES += -I$(MKFILE_PATH) -I$(MKFILE_PATH)/arch/x86/
+INCLUDES += -I$(MKFILE_PATH) -I$(ARCH_PATH)
diff --git a/examples/performance-thread/common/lthread.c
b/examples/performance-thread/common/lthread.c
index 062275a43..7d76c8c46 100644
--- a/examples/performance-thread/common/lthread.c
+++ b/examples/performance-thread/common/lthread.c
@@ -76,6 +76,7 @@
#include
#include
+#include
#include "lthread_api.h"
#include "lthread.h"
@@ -190,19 +191,11 @@ _lthread_init(struct lthread *lt,
*/
void _lthread_set_stack(struct lthread *lt, void *stack, size_t stack_size)
{
- char *stack_top = (char *)stack + stack_size;
- void **s = (void **)stack_top;
-
/* set stack */
lt->stack = stack;
lt->stack_size = stack_size;
- /* set initial context */
- s[-3] = NULL;
- s[-2] = (void *)lt;
- lt->ctx.rsp = (void *)(stack_top - (4 * sizeof(void *)));
- lt->ctx.rbp = (void *)(stack_top - (3 * sizeof(void *)));
- lt->ctx.rip = (void *)_lthread_exec;
+ arch_set_stack(lt, _lthread_exec);
}
/*
--
2.12.2
[dpdk-dev] [PATCH v2 2/2] examples/performance-thread: add arm64 support
Updated Makefile to allow compilation for arm64 architecture. Added necessary arm64 support for lthread. Fixed minor compilation errors for arm64 compilation. Tested the apps l3fwd-thread and lthread_pthread_shim on thunderx and x86_64. Signed-off-by: Ashwin Sekhar T K --- examples/performance-thread/Makefile | 4 +- .../performance-thread/common/arch/arm64/ctx.c | 99 ++ .../performance-thread/common/arch/arm64/ctx.h | 95 ++ .../performance-thread/common/arch/arm64/stack.h | 111 + examples/performance-thread/common/common.mk | 2 + examples/performance-thread/l3fwd-thread/main.c| 2 +- 6 files changed, 310 insertions(+), 3 deletions(-) create mode 100644 examples/performance-thread/common/arch/arm64/ctx.c create mode 100644 examples/performance-thread/common/arch/arm64/ctx.h create mode 100644 examples/performance-thread/common/arch/arm64/stack.h diff --git a/examples/performance-thread/Makefile b/examples/performance-thread/Makefile index d19f8489e..0c5edfdb9 100644 --- a/examples/performance-thread/Makefile +++ b/examples/performance-thread/Makefile @@ -38,8 +38,8 @@ RTE_TARGET ?= x86_64-native-linuxapp-gcc include $(RTE_SDK)/mk/rte.vars.mk -ifneq ($(CONFIG_RTE_ARCH),"x86_64") -$(error This application is only supported for x86_64 targets) +ifeq ($(filter y,$(CONFIG_RTE_ARCH_X86_64) $(CONFIG_RTE_ARCH_ARM64)),) +$(error This application is only supported for x86_64 and arm64 targets) endif DIRS-y += l3fwd-thread diff --git a/examples/performance-thread/common/arch/arm64/ctx.c b/examples/performance-thread/common/arch/arm64/ctx.c new file mode 100644 index 0..7073cfd75 --- /dev/null +++ b/examples/performance-thread/common/arch/arm64/ctx.c @@ -0,0 +1,99 @@ +/* + * BSD LICENSE + * + * Copyright (C) Cavium networks Ltd. 2017. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of Cavium networks nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +/* + * https://github.com/halayli/lthread which carries the following license. + * + * Copyright (C) 2012, Hasan Alayli + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. 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. + * + * THIS SOFTWARE IS PROVIDED BY AUTHOR 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 AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +#include + +void +ctx_switch(struct ctx *new_ctx __rte_unused, struct c
Re: [dpdk-dev] [PATCH] examples/performance-thread: add arm64 support
On Thu, 2017-05-18 at 14:35 +0800, Jianbo Liu wrote: > On 18 May 2017 at 02:44, Jerin Jacob > wrote: > > > > -Original Message- > > > > > > Date: Wed, 17 May 2017 11:19:49 -0700 > > > From: Ashwin Sekhar T K > > > To: jerin.ja...@caviumnetworks.com, john.mcnam...@intel.com, > > > jianbo@linaro.org > > > Cc: dev@dpdk.org, Ashwin Sekhar T K > > .com> > > > Subject: [dpdk-dev] [PATCH] examples/performance-thread: add > > > arm64 support > > > X-Mailer: git-send-email 2.12.2 > > > > > > Updated Makefile to allow compilation for arm64 architecture. > > > > > > Moved the code for setting the initial stack to architecture > > > specific > > > directory. > > Please split the patch to two > > - "arch_set_stack" abstraction and associated x86 change > > - arm64 support > There are so many redundant code in l3fwd and l3fwd-thread, I think > it's possible to merge them. > Yes. But I think its better to do them as a completely separate patch set. > > > > > > Thanks Ashwin. > > > > I think, This may be the last feature to make arm64 at par with x86 > > features > > supported in DPDK. > > > > /Jerin
Re: [dpdk-dev] [PATCH 2/6] eal/arm32: rte pause implementation for arm32
On Thu, 11 May 2017 15:40:42 +0530 Jerin Jacob wrote: > The patch does not provide any functional change for ARM32 > with respect to existing rte_pause() definition. > > CC: Jan Viktorin > CC: Jianbo Liu > Signed-off-by: Jerin Jacob Acked-by: Jan Viktorin
Re: [dpdk-dev] [PATCH] vhost: check malloc return value when allocating guest pages
On 05/11/2017 05:25 PM, Jens Freimann wrote:
When we try to allocate guest pages we need to check the return value of
malloc(). Print an error message and return when it fails.
Signed-off-by: Jens Freimann
---
lib/librte_vhost/vhost_user.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 5c8058b..437e41f 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -515,6 +515,13 @@ vhost_user_set_mem_table(struct virtio_net *dev, struct
VhostUserMsg *pmsg)
dev->max_guest_pages = 8;
dev->guest_pages = malloc(dev->max_guest_pages *
sizeof(struct guest_page));
+ if (dev->guest_pages == NULL) {
+ RTE_LOG(ERR, VHOST_CONFIG,
+ "(%d) failed to allocate memory "
+ "for dev->guest_pages\n",
+ dev->vid);
+ return -1;
+ }
}
dev->mem = rte_zmalloc("vhost-mem-table", sizeof(struct rte_vhost_memory) +
Reviewed-by: Maxime Coquelin
Thanks!
Maxime
[dpdk-dev] [PATCH] eventdev: define the default value for dequeue timeout
Defining the value 0 as default value for dequeue timeout
will help the application reduce the configuration setup
if the application is interested only in default
timeout value.
Signed-off-by: Jerin Jacob
---
This patch will fix following error found in the event_pipeline RFC application
http://dpdk.org/dev/patchwork/patch/23799/ with event_octeontx HW driver.
EVENTDEV: rte_event_dev_configure() line 379: dev0 invalid
dequeue_timeout_ns=0 min_dequeue_timeout_ns=853 max_dequeue_timeout_ns=873813
---
drivers/event/octeontx/ssovf_evdev.c | 2 ++
lib/librte_eventdev/rte_eventdev.c | 5 +++--
lib/librte_eventdev/rte_eventdev.h | 1 +
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/event/octeontx/ssovf_evdev.c
b/drivers/event/octeontx/ssovf_evdev.c
index c80a44379..5499b1bf7 100644
--- a/drivers/event/octeontx/ssovf_evdev.c
+++ b/drivers/event/octeontx/ssovf_evdev.c
@@ -194,6 +194,8 @@ ssovf_configure(const struct rte_eventdev *dev)
ssovf_func_trace();
deq_tmo_ns = conf->dequeue_timeout_ns;
+ if (deq_tmo_ns == 0)
+ deq_tmo_ns = edev->min_deq_timeout_ns;
if (conf->event_dev_cfg & RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT) {
edev->is_timeout_deq = 1;
diff --git a/lib/librte_eventdev/rte_eventdev.c
b/lib/librte_eventdev/rte_eventdev.c
index 20afc3f0e..8cafffe03 100644
--- a/lib/librte_eventdev/rte_eventdev.c
+++ b/lib/librte_eventdev/rte_eventdev.c
@@ -369,9 +369,10 @@ rte_event_dev_configure(uint8_t dev_id,
/* Check dequeue_timeout_ns value is in limit */
if (!(dev_conf->event_dev_cfg & RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT))
{
- if (dev_conf->dequeue_timeout_ns < info.min_dequeue_timeout_ns
+ if (dev_conf->dequeue_timeout_ns &&
+ (dev_conf->dequeue_timeout_ns < info.min_dequeue_timeout_ns
|| dev_conf->dequeue_timeout_ns >
-info.max_dequeue_timeout_ns) {
+info.max_dequeue_timeout_ns)) {
RTE_EDEV_LOG_ERR("dev%d invalid dequeue_timeout_ns=%d"
" min_dequeue_timeout_ns=%d max_dequeue_timeout_ns=%d",
dev_id, dev_conf->dequeue_timeout_ns,
diff --git a/lib/librte_eventdev/rte_eventdev.h
b/lib/librte_eventdev/rte_eventdev.h
index 94284337d..f39fbc6b9 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -409,6 +409,7 @@ struct rte_event_dev_config {
* This value should be in the range of *min_dequeue_timeout_ns* and
* *max_dequeue_timeout_ns* which previously provided in
* rte_event_dev_info_get()
+* The value 0 is allowed, in which case, default dequeue timeout used.
* @see RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT
*/
int32_t nb_events_limit;
--
2.13.0
Re: [dpdk-dev] [PATCH v8] net/i40e: improved FDIR programming times
On 5/18/2017 2:38 AM, Xing, Beilei wrote: > Hi, > >> -Original Message- >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Michael Lilja >> Sent: Wednesday, May 17, 2017 10:58 PM >> To: Zhang, Helin ; Wu, Jingjing >> >> Cc: dev@dpdk.org; Michael Lilja >> Subject: [dpdk-dev] [PATCH v8] net/i40e: improved FDIR programming times >> >> Previously, the FDIR programming time is +11ms on i40e. >> This patch will result in an average programming time of 22usec with a max of >> 60usec . >> >> Signed-off-by: Michael Lilja > Acked-by: Beilei Xing Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH v2 2/2] examples/performance-thread: add arm64 support
-Original Message-
> Date: Thu, 18 May 2017 00:34:26 -0700
> From: Ashwin Sekhar T K
> To: jerin.ja...@caviumnetworks.com, john.mcnam...@intel.com,
> jianbo@linaro.org
> Cc: dev@dpdk.org, Ashwin Sekhar T K
> Subject: [dpdk-dev] [PATCH v2 2/2] examples/performance-thread: add arm64
> support
> X-Mailer: git-send-email 2.12.2
>
> Updated Makefile to allow compilation for arm64 architecture.
>
> Added necessary arm64 support for lthread.
>
> Fixed minor compilation errors for arm64 compilation.
>
> Tested the apps l3fwd-thread and lthread_pthread_shim on thunderx
> and x86_64.
>
> +void
> +ctx_switch(struct ctx *new_ctx __rte_unused, struct ctx *curr_ctx
> __rte_unused)
> +{
> + /* SAVE CURRENT CONTEXT */
> + asm volatile (
> + /* Save SP */
> + "mov x3, sp\n"
> + "str x3, [x1, #0]\n"
> +
> + /* Save FP and LR */
> + "stp x29, x30, [x1, #8]\n"
> +
> + /* Save Callee Saved Regs x19 - x28 */
> + "stp x19, x20, [x1, #24]\n"
> + "stp x21, x22, [x1, #40]\n"
> + "stp x23, x24, [x1, #56]\n"
> + "stp x25, x26, [x1, #72]\n"
> + "stp x27, x28, [x1, #88]\n"
> + );
IMO, We need to save SIMD registers in the context as well.
x86 code also not doing that, looks like it is an obvious bug in x86 code as
well.
Re: [dpdk-dev] [PATCH v2 2/2] examples/performance-thread: add arm64 support
On Thu, 2017-05-18 at 14:25 +0530, Jerin Jacob wrote:
> -Original Message-
> >
> > Date: Thu, 18 May 2017 00:34:26 -0700
> > From: Ashwin Sekhar T K
> > To: jerin.ja...@caviumnetworks.com, john.mcnam...@intel.com,
> > jianbo@linaro.org
> > Cc: dev@dpdk.org, Ashwin Sekhar T K > om>
> > Subject: [dpdk-dev] [PATCH v2 2/2] examples/performance-thread: add
> > arm64
> > support
> > X-Mailer: git-send-email 2.12.2
> >
> > Updated Makefile to allow compilation for arm64 architecture.
> >
> > Added necessary arm64 support for lthread.
> >
> > Fixed minor compilation errors for arm64 compilation.
> >
> > Tested the apps l3fwd-thread and lthread_pthread_shim on thunderx
> > and x86_64.
> >
> > +void
> > +ctx_switch(struct ctx *new_ctx __rte_unused, struct ctx *curr_ctx
> > __rte_unused)
> > +{
> > + /* SAVE CURRENT CONTEXT */
> > + asm volatile (
> > + /* Save SP */
> > + "mov x3, sp\n"
> > + "str x3, [x1, #0]\n"
> > +
> > + /* Save FP and LR */
> > + "stp x29, x30, [x1, #8]\n"
> > +
> > + /* Save Callee Saved Regs x19 - x28 */
> > + "stp x19, x20, [x1, #24]\n"
> > + "stp x21, x22, [x1, #40]\n"
> > + "stp x23, x24, [x1, #56]\n"
> > + "stp x25, x26, [x1, #72]\n"
> > + "stp x27, x28, [x1, #88]\n"
> > + );
> IMO, We need to save SIMD registers in the context as well.
> x86 code also not doing that, looks like it is an obvious bug in x86
> code as
> well.
>
Yes. You are correct. Need to save the bottom 64-bits of called saved
ASIMD regs v8-v15. Will update the patch.
Re: [dpdk-dev] [RFC][PATCH] vfio: allow to map other memory regions
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Wednesday, May 17, 2017 7:20 PM
> To: Wodkowski, PawelX
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC][PATCH] vfio: allow to map other memory regions
>
> On Wed, 17 May 2017 16:44:46 +0200
> Pawel Wodkowski wrote:
>
> > /* IOMMU types we support */
> > static const struct vfio_iommu_type iommu_types[] = {
> > /* x86 IOMMU, otherwise known as type 1 */
> > - { RTE_VFIO_TYPE1, "Type 1", &vfio_type1_dma_map},
> > + { RTE_VFIO_TYPE1, "Type 1", &vfio_type1_dma_map,
> &vfio_type1_dma_mem_map},
> > /* ppc64 IOMMU, otherwise known as spapr */
> > - { RTE_VFIO_SPAPR, "sPAPR", &vfio_spapr_dma_map},
> > + { RTE_VFIO_SPAPR, "sPAPR", &vfio_spapr_dma_map, NULL},
> > /* IOMMU-less mode */
> > - { RTE_VFIO_NOIOMMU, "No-IOMMU", &vfio_noiommu_dma_map},
> > + { RTE_VFIO_NOIOMMU, "No-IOMMU", &vfio_noiommu_dma_map,
> &vfio_noiommu_dma_mem_map},
> > };
>
> For complex tables like this why not use C99 style initializer.
Sure will change it in next version.
Any comments about functional side of this change before v2 ? :)
Pawel
[dpdk-dev] [PATCH] examples/ip_pipeline: use crc32 in hash functions for arm64
Implement the same hash functions with crc32 on arm platform.
Signed-off-by: Jianbo Liu
---
examples/ip_pipeline/pipeline/hash_func.h | 2 +
examples/ip_pipeline/pipeline/hash_func_arm64.h | 245
2 files changed, 247 insertions(+)
create mode 100644 examples/ip_pipeline/pipeline/hash_func_arm64.h
diff --git a/examples/ip_pipeline/pipeline/hash_func.h
b/examples/ip_pipeline/pipeline/hash_func.h
index 9db7173..990bbee 100644
--- a/examples/ip_pipeline/pipeline/hash_func.h
+++ b/examples/ip_pipeline/pipeline/hash_func.h
@@ -335,6 +335,8 @@
#define hash_default_key56 hash_crc_key56
#define hash_default_key64 hash_crc_key64
+#elif defined(RTE_ARCH_ARM64)
+#include "hash_func_arm64.h"
#else
#define hash_default_key8 hash_xor_key8
diff --git a/examples/ip_pipeline/pipeline/hash_func_arm64.h
b/examples/ip_pipeline/pipeline/hash_func_arm64.h
new file mode 100644
index 000..f6a45d9
--- /dev/null
+++ b/examples/ip_pipeline/pipeline/hash_func_arm64.h
@@ -0,0 +1,245 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2017 Linaro Limited. 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.
+ */
+#ifndef __HASH_FUNC_ARM64_H__
+#define __HASH_FUNC_ARM64_H__
+
+#define _CRC32CX(crc, val) \
+ __asm__("crc32cx %w[c], %w[c], %x[v]":[c] "+r" (crc):[v] "r" (val))
+
+static inline uint64_t
+hash_crc_key8(void *key, __rte_unused uint32_t key_size, uint64_t seed)
+{
+ uint64_t *k = key;
+ uint32_t crc0;
+
+ crc0 = seed;
+ _CRC32CX(crc0, k[0]);
+
+ return crc0;
+}
+
+static inline uint64_t
+hash_crc_key16(void *key, __rte_unused uint32_t key_size, uint64_t seed)
+{
+ uint64_t *k = key, k0;
+ uint32_t crc0, crc1;
+
+ k0 = k[0];
+
+ crc0 = k0;
+ _CRC32CX(crc0, seed);
+ crc1 = k0 >> 32;
+ _CRC32CX(crc1, k[1]);
+
+ crc0 ^= crc1;
+
+ return crc0;
+}
+
+static inline uint64_t
+hash_crc_key24(void *key, __rte_unused uint32_t key_size, uint64_t seed)
+{
+ uint64_t *k = key, k0, k2;
+ uint32_t crc0, crc1;
+
+ k0 = k[0];
+ k2 = k[2];
+
+ crc0 = k0;
+ _CRC32CX(crc0, seed);
+ crc1 = k0 >> 32;
+ _CRC32CX(crc1, k[1]);
+
+ _CRC32CX(crc0, k2);
+
+ crc0 ^= crc1;
+
+ return crc0;
+}
+
+static inline uint64_t
+hash_crc_key32(void *key, __rte_unused uint32_t key_size, uint64_t seed)
+{
+ uint64_t *k = key, k0, k2;
+ uint32_t crc0, crc1, crc2, crc3;
+
+ k0 = k[0];
+ k2 = k[2];
+
+ crc0 = k0;
+ _CRC32CX(crc0, seed);
+ crc1 = k0 >> 32;
+ _CRC32CX(crc1, k[1]);
+
+ crc2 = k2;
+ _CRC32CX(crc2, k[3]);
+ crc3 = k2 >> 32;
+
+ _CRC32CX(crc0, crc1);
+ _CRC32CX(crc2, crc3);
+
+ crc0 ^= crc2;
+
+ return crc0;
+}
+
+static inline uint64_t
+hash_crc_key40(void *key, __rte_unused uint32_t key_size, uint64_t seed)
+{
+ uint64_t *k = key, k0, k2;
+ uint32_t crc0, crc1, crc2, crc3;
+
+ k0 = k[0];
+ k2 = k[2];
+
+ crc0 = k0;
+ _CRC32CX(crc0, seed);
+ crc1 = k0 >> 32;
+ _CRC32CX(crc1, k[1]);
+
+ crc2 = k2;
+ _CRC32CX(crc2, k[3]);
+ crc3 = k2 >> 32;
+ _CRC32CX(crc3, k[4]);
+
+ _CRC32CX(crc0, crc1);
+ _CRC32CX(crc2, crc3);
+
+ crc0 ^= crc2;
+
+ return crc0;
+}
+
+s
[dpdk-dev] [PATCH] app/testpmd: add TCP flags in flow API
This commit adds TCP flags support in flow API as
some drivers have SYN filter.
Signed-off-by: Beilei Xing
---
app/test-pmd/cmdline_flow.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 0fd69f9..3e5803a 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -152,6 +152,7 @@ enum index {
ITEM_TCP,
ITEM_TCP_SRC,
ITEM_TCP_DST,
+ ITEM_TCP_FLAGS,
ITEM_SCTP,
ITEM_SCTP_SRC,
ITEM_SCTP_DST,
@@ -531,6 +532,7 @@ static const enum index item_udp[] = {
static const enum index item_tcp[] = {
ITEM_TCP_SRC,
ITEM_TCP_DST,
+ ITEM_TCP_FLAGS,
ITEM_NEXT,
ZERO,
};
@@ -1267,6 +1269,13 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_tcp,
hdr.dst_port)),
},
+ [ITEM_TCP_FLAGS] = {
+ .name = "flags",
+ .help = "TCP flags",
+ .next = NEXT(item_tcp, NEXT_ENTRY(UNSIGNED), item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_tcp,
+hdr.tcp_flags)),
+ },
[ITEM_SCTP] = {
.name = "sctp",
.help = "match SCTP header",
--
2.5.5
Re: [dpdk-dev] [PATCH 2/6] eal/arm32: rte pause implementation for arm32
On 18 May 2017 at 16:11, Jan Viktorin wrote: > On Thu, 11 May 2017 15:40:42 +0530 > Jerin Jacob wrote: > >> The patch does not provide any functional change for ARM32 >> with respect to existing rte_pause() definition. >> >> CC: Jan Viktorin >> CC: Jianbo Liu >> Signed-off-by: Jerin Jacob > > Acked-by: Jan Viktorin Acked-by: Jianbo Liu
Re: [dpdk-dev] [PATCH] app/testpmd: add TCP flags in flow API
Test that patch use flow API of igb NIC syn filter, it is ok.
Acked-by: Wei Zhao
> -Original Message-
> From: Xing, Beilei
> Sent: Thursday, May 18, 2017 5:06 PM
> To: adrien.mazarg...@6wind.com
> Cc: dev@dpdk.org; Zhao1, Wei
> Subject: [PATCH] app/testpmd: add TCP flags in flow API
>
> This commit adds TCP flags support in flow API as some drivers have SYN
> filter.
>
> Signed-off-by: Beilei Xing
> ---
> app/test-pmd/cmdline_flow.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index 0fd69f9..3e5803a 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -152,6 +152,7 @@ enum index {
> ITEM_TCP,
> ITEM_TCP_SRC,
> ITEM_TCP_DST,
> + ITEM_TCP_FLAGS,
> ITEM_SCTP,
> ITEM_SCTP_SRC,
> ITEM_SCTP_DST,
> @@ -531,6 +532,7 @@ static const enum index item_udp[] = { static const
> enum index item_tcp[] = {
> ITEM_TCP_SRC,
> ITEM_TCP_DST,
> + ITEM_TCP_FLAGS,
> ITEM_NEXT,
> ZERO,
> };
> @@ -1267,6 +1269,13 @@ static const struct token token_list[] = {
> .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_tcp,
>hdr.dst_port)),
> },
> + [ITEM_TCP_FLAGS] = {
> + .name = "flags",
> + .help = "TCP flags",
> + .next = NEXT(item_tcp, NEXT_ENTRY(UNSIGNED),
> item_param),
> + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_tcp,
> + hdr.tcp_flags)),
> + },
> [ITEM_SCTP] = {
> .name = "sctp",
> .help = "match SCTP header",
> --
> 2.5.5
Re: [dpdk-dev] [PATCH] app/testpmd: add TCP flags in flow API
On Thu, May 18, 2017 at 05:06:12PM +0800, Beilei Xing wrote: > This commit adds TCP flags support in flow API as > some drivers have SYN filter. > > Signed-off-by: Beilei Xing Acked-by: Adrien Mazarguil -- Adrien Mazarguil 6WIND
[dpdk-dev] [PATCH] net/i40e: add NVGRE parsing function
This patch adds NVGRE parsing function to support NVGRE
classification.
Signed-off-by: Beilei Xing
---
drivers/net/i40e/i40e_flow.c | 338 ++-
1 file changed, 336 insertions(+), 2 deletions(-)
diff --git a/drivers/net/i40e/i40e_flow.c b/drivers/net/i40e/i40e_flow.c
index 8d1fcde..6c97019 100644
--- a/drivers/net/i40e/i40e_flow.c
+++ b/drivers/net/i40e/i40e_flow.c
@@ -114,6 +114,12 @@ static int i40e_flow_parse_vxlan_filter(struct rte_eth_dev
*dev,
const struct rte_flow_action actions[],
struct rte_flow_error *error,
union i40e_filter_t *filter);
+static int i40e_flow_parse_nvgre_filter(struct rte_eth_dev *dev,
+ const struct rte_flow_attr *attr,
+ const struct rte_flow_item pattern[],
+ const struct rte_flow_action actions[],
+ struct rte_flow_error *error,
+ union i40e_filter_t *filter);
static int i40e_flow_parse_mpls_filter(struct rte_eth_dev *dev,
const struct rte_flow_attr *attr,
const struct rte_flow_item pattern[],
@@ -296,7 +302,40 @@ static enum rte_flow_item_type pattern_vxlan_4[] = {
RTE_FLOW_ITEM_TYPE_END,
};
-/* Pattern matched MPLS */
+static enum rte_flow_item_type pattern_nvgre_1[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV4,
+ RTE_FLOW_ITEM_TYPE_NVGRE,
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+static enum rte_flow_item_type pattern_nvgre_2[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_NVGRE,
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+static enum rte_flow_item_type pattern_nvgre_3[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV4,
+ RTE_FLOW_ITEM_TYPE_NVGRE,
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+static enum rte_flow_item_type pattern_nvgre_4[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_NVGRE,
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_VLAN,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
static enum rte_flow_item_type pattern_mpls_1[] = {
RTE_FLOW_ITEM_TYPE_ETH,
RTE_FLOW_ITEM_TYPE_IPV4,
@@ -329,7 +368,6 @@ static enum rte_flow_item_type pattern_mpls_4[] = {
RTE_FLOW_ITEM_TYPE_END,
};
-/* Pattern matched QINQ */
static enum rte_flow_item_type pattern_qinq_1[] = {
RTE_FLOW_ITEM_TYPE_ETH,
RTE_FLOW_ITEM_TYPE_VLAN,
@@ -362,6 +400,11 @@ static struct i40e_valid_pattern i40e_supported_patterns[]
= {
{ pattern_vxlan_2, i40e_flow_parse_vxlan_filter },
{ pattern_vxlan_3, i40e_flow_parse_vxlan_filter },
{ pattern_vxlan_4, i40e_flow_parse_vxlan_filter },
+ /* NVGRE */
+ { pattern_nvgre_1, i40e_flow_parse_nvgre_filter },
+ { pattern_nvgre_2, i40e_flow_parse_nvgre_filter },
+ { pattern_nvgre_3, i40e_flow_parse_nvgre_filter },
+ { pattern_nvgre_4, i40e_flow_parse_nvgre_filter },
/* MPLSoUDP & MPLSoGRE */
{ pattern_mpls_1, i40e_flow_parse_mpls_filter },
{ pattern_mpls_2, i40e_flow_parse_mpls_filter },
@@ -1589,6 +1632,297 @@ i40e_flow_parse_vxlan_filter(struct rte_eth_dev *dev,
}
/* 1. Last in item should be NULL as range is not supported.
+ * 2. Supported filter types: IMAC_IVLAN_TENID, IMAC_IVLAN,
+ *IMAC_TENID, OMAC_TENID_IMAC and IMAC.
+ * 3. Mask of fields which need to be matched should be
+ *filled with 1.
+ * 4. Mask of fields which needn't to be matched should be
+ *filled with 0.
+ */
+static int
+i40e_flow_parse_nvgre_pattern(__rte_unused struct rte_eth_dev *dev,
+ const struct rte_flow_item *pattern,
+ struct rte_flow_error *error,
+ struct i40e_tunnel_filter_conf *filter)
+{
+ const struct rte_flow_item *item = pattern;
+ const struct rte_flow_item_eth *eth_spec;
+ const struct rte_flow_item_eth *eth_mask;
+ const struct rte_flow_item_eth *o_eth_spec = NULL;
+ const struct rte_flow_item_eth *o_eth_mask = NULL;
+ const struct rte_flow_item_nvgre *nvgre_spec = NULL;
+ const struct rte_flow_item_nvgre *nvgre_mask = NULL;
+ const struct rte_flow_item_eth *i_eth_spec = NULL;
+ const struct rte_flow_item_eth *i_eth_mask = NULL;
+ const struct rte_flow_item_vlan *vlan_spec = NULL;
+ const struct rte_flow_item_vlan *vlan_mask = NULL;
+ bool is_tni_masked = 0;
+ enum rte_flow_item_type item_type;
+ bool nvgre_flag = 0;
+ uint32_t tenant_id_be = 0;
+
+ for (; item->typ
Re: [dpdk-dev] [PATCH 3/6] eal/arm64: rte pause implementation for arm64
On 11 May 2017 at 18:10, Jerin Jacob wrote:
> CC: Jianbo Liu
> Signed-off-by: Jerin Jacob
> ---
> lib/librte_eal/common/include/arch/arm/rte_pause.h | 4 ++
> .../common/include/arch/arm/rte_pause_64.h | 55
> ++
> 2 files changed, 59 insertions(+)
> create mode 100644 lib/librte_eal/common/include/arch/arm/rte_pause_64.h
>
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_pause.h
> b/lib/librte_eal/common/include/arch/arm/rte_pause.h
> index 0fe88aba9..9b79405e6 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_pause.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_pause.h
> @@ -37,7 +37,11 @@
> extern "C" {
> #endif
>
> +#ifdef RTE_ARCH_64
> +#include
> +#else
> #include
> +#endif
>
> #ifdef __cplusplus
> }
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_pause_64.h
> b/lib/librte_eal/common/include/arch/arm/rte_pause_64.h
> new file mode 100644
> index 0..cae996de8
> --- /dev/null
> +++ b/lib/librte_eal/common/include/arch/arm/rte_pause_64.h
> @@ -0,0 +1,55 @@
> +/*
> + * BSD LICENSE
> + *
> + * Copyright(c) 2017 Cavium. All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + * * Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + * * Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + * * Neither the name of Cavium 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.
> + */
> +
> +#ifndef _RTE_PAUSE_ARM64_H_
> +#define _RTE_PAUSE_ARM64_H_
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include
> +#include "generic/rte_pause.h"
> +
> +static inline void rte_pause(void)
> +{
> + /* YIELD hints the CPU to switch to another thread if possible
> +* and executes as a NOP otherwise.
I think you can remove the second line if you are trying to explain
what YIELD instruction is.
And I wonder if it can save power as rte_thread is bounded to certain
core and always polling while YIELD is only a hint instruction.
> +*/
> + asm volatile("yield" ::: "memory");
> +}
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* _RTE_PAUSE_ARM64_H_ */
> --
> 2.12.2
>
Re: [dpdk-dev] [PATCH 1/3] examples/eventdev_pipeline: added sample app
On Wed, May 17, 2017 at 11:33:16PM +0530, Jerin Jacob wrote:
> -Original Message-
> > Date: Fri, 21 Apr 2017 10:51:37 +0100
> > From: Harry van Haaren
> > To: dev@dpdk.org
> > CC: jerin.ja...@caviumnetworks.com, Harry van Haaren
> > , Gage Eads , Bruce
> > Richardson
> > Subject: [PATCH 1/3] examples/eventdev_pipeline: added sample app
> > X-Mailer: git-send-email 2.7.4
> >
> > This commit adds a sample app for the eventdev library.
> > The app has been tested with DPDK 17.05-rc2, hence this
> > release (or later) is recommended.
> >
> > The sample app showcases a pipeline processing use-case,
> > with event scheduling and processing defined per stage.
> > The application recieves traffic as normal, with each
> > packet traversing the pipeline. Once the packet has
> > been processed by each of the pipeline stages, it is
> > transmitted again.
> >
> > The app provides a framework to utilize cores for a single
> > role or multiple roles. Examples of roles are the RX core,
> > TX core, Scheduling core (in the case of the event/sw PMD),
> > and worker cores.
> >
> > Various flags are available to configure numbers of stages,
> > cycles of work at each stage, type of scheduling, number of
> > worker cores, queue depths etc. For a full explaination,
> > please refer to the documentation.
> >
> > Signed-off-by: Gage Eads
> > Signed-off-by: Bruce Richardson
> > Signed-off-by: Harry van Haaren
> > ---
> > +
> > +static inline void
> > +schedule_devices(uint8_t dev_id, unsigned lcore_id)
> > +{
> > + if (rx_core[lcore_id] && (rx_single ||
> > + rte_atomic32_cmpset(&rx_lock, 0, 1))) {
> > + producer();
> > + rte_atomic32_clear((rte_atomic32_t *)&rx_lock);
> > + }
> > +
> > + if (sched_core[lcore_id] && (sched_single ||
> > + rte_atomic32_cmpset(&sched_lock, 0, 1))) {
> > + rte_event_schedule(dev_id);
>
> One question here,
>
> Does rte_event_schedule()'s SW PMD implementation capable of running
> concurrently on multiple cores?
>
No, it's not. It's designed to be called on a single (dedicated) core.
> Context:
> Currently I am writing a testpmd like test framework to realize
> different use cases along with with performance test cases like throughput
> and latency and making sure it works on SW and HW driver.
>
> I see the following segfault problem when rte_event_schedule() invoked on
> multiple core currently. Is it expected?
Yes,pretty much.
/Bruce
[dpdk-dev] [PATCH 1/2] eal: add static endianness conversion macros
These macros resolve to constant expressions that allow developers to
perform endianness conversion on static/const objects, even outside of
function scope as they do not translate to function calls.
This is most useful for static initializers and constant values (whenever
it has to be performed at compilation time). Run-time endianness conversion
of variable values should keep using rte_*_to_*() calls for best
performance.
Signed-off-by: Adrien Mazarguil
---
.../common/include/generic/rte_byteorder.h | 58 +++-
1 file changed, 44 insertions(+), 14 deletions(-)
diff --git a/lib/librte_eal/common/include/generic/rte_byteorder.h
b/lib/librte_eal/common/include/generic/rte_byteorder.h
index e00bccb..8408872 100644
--- a/lib/librte_eal/common/include/generic/rte_byteorder.h
+++ b/lib/librte_eal/common/include/generic/rte_byteorder.h
@@ -74,6 +74,47 @@
#elif defined __LITTLE_ENDIAN__
#define RTE_BYTE_ORDER RTE_LITTLE_ENDIAN
#endif
+#if !defined(RTE_BYTE_ORDER)
+#error Unknown endianness.
+#endif
+
+#define RTE_STATIC_BSWAP16(v) \
+ uint16_t)(v) & UINT16_C(0x00ff)) << 8) | \
+(((uint16_t)(v) & UINT16_C(0xff00)) >> 8))
+
+#define RTE_STATIC_BSWAP32(v) \
+ uint32_t)(v) & UINT32_C(0x00ff)) << 24) | \
+(((uint32_t)(v) & UINT32_C(0xff00)) << 8) | \
+(((uint32_t)(v) & UINT32_C(0x00ff)) >> 8) | \
+(((uint32_t)(v) & UINT32_C(0xff00)) >> 24))
+
+#define RTE_STATIC_BSWAP64(v) \
+ uint64_t)(v) & UINT64_C(0x00ff)) << 56) | \
+(((uint64_t)(v) & UINT64_C(0xff00)) << 40) | \
+(((uint64_t)(v) & UINT64_C(0x00ff)) << 24) | \
+(((uint64_t)(v) & UINT64_C(0xff00)) << 8) | \
+(((uint64_t)(v) & UINT64_C(0x00ff)) >> 8) | \
+(((uint64_t)(v) & UINT64_C(0xff00)) >> 24) | \
+(((uint64_t)(v) & UINT64_C(0x00ff)) >> 40) | \
+(((uint64_t)(v) & UINT64_C(0xff00)) >> 56))
+
+#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+#define RTE_BE16(v) (uint16_t)(v)
+#define RTE_BE32(v) (uint32_t)(v)
+#define RTE_BE64(v) (uint64_t)(v)
+#define RTE_LE16(v) RTE_STATIC_BSWAP16(v)
+#define RTE_LE32(v) RTE_STATIC_BSWAP32(v)
+#define RTE_LE64(v) RTE_STATIC_BSWAP64(v)
+#elif RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+#define RTE_BE16(v) RTE_STATIC_BSWAP16(v)
+#define RTE_BE32(v) RTE_STATIC_BSWAP32(v)
+#define RTE_BE64(v) RTE_STATIC_BSWAP64(v)
+#define RTE_LE16(v) (uint16_t)(v)
+#define RTE_LE32(v) (uint32_t)(v)
+#define RTE_LE64(v) (uint64_t)(v)
+#else
+#error Unsupported endianness.
+#endif
/*
* An internal function to swap bytes in a 16-bit value.
@@ -84,8 +125,7 @@
static inline uint16_t
rte_constant_bswap16(uint16_t x)
{
- return (uint16_t)(((x & 0x00ffU) << 8) |
- ((x & 0xff00U) >> 8));
+ return RTE_STATIC_BSWAP16(x);
}
/*
@@ -97,10 +137,7 @@ rte_constant_bswap16(uint16_t x)
static inline uint32_t
rte_constant_bswap32(uint32_t x)
{
- return ((x & 0x00ffUL) << 24) |
- ((x & 0xff00UL) << 8) |
- ((x & 0x00ffUL) >> 8) |
- ((x & 0xff00UL) >> 24);
+ return RTE_STATIC_BSWAP32(x);
}
/*
@@ -112,14 +149,7 @@ rte_constant_bswap32(uint32_t x)
static inline uint64_t
rte_constant_bswap64(uint64_t x)
{
- return ((x & 0x00ffULL) << 56) |
- ((x & 0xff00ULL) << 40) |
- ((x & 0x00ffULL) << 24) |
- ((x & 0xff00ULL) << 8) |
- ((x & 0x00ffULL) >> 8) |
- ((x & 0xff00ULL) >> 24) |
- ((x & 0x00ffULL) >> 40) |
- ((x & 0xff00ULL) >> 56);
+ return RTE_STATIC_BSWAP64(x);
}
--
2.1.4
[dpdk-dev] [PATCH 2/2] ethdev: tidy up endianness handling in flow API
Signed-off-by: Adrien Mazarguil
---
lib/librte_ether/rte_flow.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index c47edbc..02dcfe7 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -624,13 +624,7 @@ struct rte_flow_item_e_tag {
/** Default mask for RTE_FLOW_ITEM_TYPE_E_TAG. */
#ifndef __cplusplus
static const struct rte_flow_item_e_tag rte_flow_item_e_tag_mask = {
-#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
- .rsvd_grp_ecid_b = 0x3fff,
-#elif RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
- .rsvd_grp_ecid_b = 0xff3f,
-#else
-#error Unsupported endianness.
-#endif
+ .rsvd_grp_ecid_b = RTE_BE16(0x3fff),
};
#endif
--
2.1.4
Re: [dpdk-dev] [PATCH 3/6] eal/arm64: rte pause implementation for arm64
-Original Message-
> Date: Thu, 18 May 2017 17:40:58 +0800
> From: Jianbo Liu
> To: Jerin Jacob
> Cc: dev@dpdk.org, tho...@monjalon.net, Jan Viktorin
>
> Subject: Re: [dpdk-dev] [PATCH 3/6] eal/arm64: rte pause implementation for
> arm64
>
> On 11 May 2017 at 18:10, Jerin Jacob wrote:
> > CC: Jianbo Liu
> > Signed-off-by: Jerin Jacob
> > ---
> > lib/librte_eal/common/include/arch/arm/rte_pause.h | 4 ++
> > .../common/include/arch/arm/rte_pause_64.h | 55
> > ++
> > 2 files changed, 59 insertions(+)
> > create mode 100644 lib/librte_eal/common/include/arch/arm/rte_pause_64.h
> >
> > diff --git a/lib/librte_eal/common/include/arch/arm/rte_pause.h
> > b/lib/librte_eal/common/include/arch/arm/rte_pause.h
> > index 0fe88aba9..9b79405e6 100644
> > --- a/lib/librte_eal/common/include/arch/arm/rte_pause.h
> > +++ b/lib/librte_eal/common/include/arch/arm/rte_pause.h
> > @@ -37,7 +37,11 @@
> > extern "C" {
> > #endif
> >
> > +#ifdef RTE_ARCH_64
> > +#include
> > +#else
> > #include
> > +#endif
> >
> > #ifdef __cplusplus
> > }
> > diff --git a/lib/librte_eal/common/include/arch/arm/rte_pause_64.h
> > b/lib/librte_eal/common/include/arch/arm/rte_pause_64.h
> > new file mode 100644
> > index 0..cae996de8
> > --- /dev/null
> > +++ b/lib/librte_eal/common/include/arch/arm/rte_pause_64.h
> > @@ -0,0 +1,55 @@
> > +/*
> > + * BSD LICENSE
> > + *
> > + * Copyright(c) 2017 Cavium. All rights reserved.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + *
> > + * * Redistributions of source code must retain the above copyright
> > + * notice, this list of conditions and the following disclaimer.
> > + * * Redistributions in binary form must reproduce the above copyright
> > + * notice, this list of conditions and the following disclaimer in
> > + * the documentation and/or other materials provided with the
> > + * distribution.
> > + * * Neither the name of Cavium 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.
> > + */
> > +
> > +#ifndef _RTE_PAUSE_ARM64_H_
> > +#define _RTE_PAUSE_ARM64_H_
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +#include
> > +#include "generic/rte_pause.h"
> > +
> > +static inline void rte_pause(void)
> > +{
> > + /* YIELD hints the CPU to switch to another thread if possible
> > +* and executes as a NOP otherwise.
>
> I think you can remove the second line if you are trying to explain
> what YIELD instruction is.
> And I wonder if it can save power as rte_thread is bounded to certain
> core and always polling while YIELD is only a hint instruction.
AFAIK, It is HW thread not software OS thread.ie Simultaneous Multi-Threading
(SMT)
or Hyper threading.
For example, Cavium 99xx has 4 HW threads per physical core.
I agree on comment. I think, I can remove the comment as YIELD is just a hint
and varies based on arm64 implementation. Will fix it v2.
>
> > +*/
> > + asm volatile("yield" ::: "memory");
> > +}
> > +
> > +#ifdef __cplusplus
> > +}
> > +#endif
> > +
> > +#endif /* _RTE_PAUSE_ARM64_H_ */
> > --
> > 2.12.2
> >
[dpdk-dev] [PATCH v3 0/2] examples/performance-thread: add arm64 support
This series of patches adds the arm64 support for performance-thread app. Patch 1 moves some x86 specific code to architecture dependent directory Patch 2 adds the necessary arm64 support for lthread. v3: * Added save/restore of callee saved ASIMD registers in ctx_switch v2: * Split the patch into separate patches, one for code reorg and another for adding arm64 support. Ashwin Sekhar T K (2): examples/performance-thread: reorganise arch dependent code examples/performance-thread: add arm64 support examples/performance-thread/Makefile | 4 +- .../performance-thread/common/arch/arm64/ctx.c | 117 + .../performance-thread/common/arch/arm64/ctx.h | 110 +++ .../performance-thread/common/arch/arm64/stack.h | 111 +++ .../performance-thread/common/arch/x86/stack.h | 66 examples/performance-thread/common/common.mk | 10 +- examples/performance-thread/common/lthread.c | 11 +- examples/performance-thread/l3fwd-thread/main.c| 2 +- 8 files changed, 417 insertions(+), 14 deletions(-) create mode 100644 examples/performance-thread/common/arch/arm64/ctx.c create mode 100644 examples/performance-thread/common/arch/arm64/ctx.h create mode 100644 examples/performance-thread/common/arch/arm64/stack.h create mode 100644 examples/performance-thread/common/arch/x86/stack.h -- 2.12.2
[dpdk-dev] [PATCH v3 2/2] examples/performance-thread: add arm64 support
Updated Makefile to allow compilation for arm64 architecture. Added necessary arm64 support for lthread. Fixed minor compilation errors for arm64 compilation. Tested the apps l3fwd-thread and lthread_pthread_shim on thunderx and x86_64. Signed-off-by: Ashwin Sekhar T K --- examples/performance-thread/Makefile | 4 +- .../performance-thread/common/arch/arm64/ctx.c | 117 + .../performance-thread/common/arch/arm64/ctx.h | 110 +++ .../performance-thread/common/arch/arm64/stack.h | 111 +++ examples/performance-thread/common/common.mk | 2 + examples/performance-thread/l3fwd-thread/main.c| 2 +- 6 files changed, 343 insertions(+), 3 deletions(-) create mode 100644 examples/performance-thread/common/arch/arm64/ctx.c create mode 100644 examples/performance-thread/common/arch/arm64/ctx.h create mode 100644 examples/performance-thread/common/arch/arm64/stack.h diff --git a/examples/performance-thread/Makefile b/examples/performance-thread/Makefile index d19f8489e..0c5edfdb9 100644 --- a/examples/performance-thread/Makefile +++ b/examples/performance-thread/Makefile @@ -38,8 +38,8 @@ RTE_TARGET ?= x86_64-native-linuxapp-gcc include $(RTE_SDK)/mk/rte.vars.mk -ifneq ($(CONFIG_RTE_ARCH),"x86_64") -$(error This application is only supported for x86_64 targets) +ifeq ($(filter y,$(CONFIG_RTE_ARCH_X86_64) $(CONFIG_RTE_ARCH_ARM64)),) +$(error This application is only supported for x86_64 and arm64 targets) endif DIRS-y += l3fwd-thread diff --git a/examples/performance-thread/common/arch/arm64/ctx.c b/examples/performance-thread/common/arch/arm64/ctx.c new file mode 100644 index 0..95ce16095 --- /dev/null +++ b/examples/performance-thread/common/arch/arm64/ctx.c @@ -0,0 +1,117 @@ +/* + * BSD LICENSE + * + * Copyright (C) Cavium networks Ltd. 2017. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of Cavium networks nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +/* + * https://github.com/halayli/lthread which carries the following license. + * + * Copyright (C) 2012, Hasan Alayli + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. 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. + * + * THIS SOFTWARE IS PROVIDED BY AUTHOR 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 AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +#include + +void +ctx_switch(struct ctx *new_ctx __rte_unused, struc
[dpdk-dev] [PATCH v3 1/2] examples/performance-thread: reorganise arch dependent code
Moved the architecture dependent stack set code to architecture
specific directory.
Signed-off-by: Ashwin Sekhar T K
---
.../performance-thread/common/arch/x86/stack.h | 66 ++
examples/performance-thread/common/common.mk | 8 ++-
examples/performance-thread/common/lthread.c | 11 +---
3 files changed, 74 insertions(+), 11 deletions(-)
create mode 100644 examples/performance-thread/common/arch/x86/stack.h
diff --git a/examples/performance-thread/common/arch/x86/stack.h
b/examples/performance-thread/common/arch/x86/stack.h
new file mode 100644
index 0..80c06bf1c
--- /dev/null
+++ b/examples/performance-thread/common/arch/x86/stack.h
@@ -0,0 +1,66 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Intel Corporation. All rights reserved.
+ * Copyright(c) Cavium networks Ltd. 2017.
+ * 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.
+ */
+
+
+#ifndef STACK_H
+#define STACK_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "lthread_int.h"
+
+/*
+ * Sets up the initial stack for the lthread.
+ */
+static inline void
+arch_set_stack(struct lthread *lt, void *func)
+{
+ char *stack_top = (char *)(lt->stack) + lt->stack_size;
+ void **s = (void **)stack_top;
+
+ /* set initial context */
+ s[-3] = NULL;
+ s[-2] = (void *)lt;
+ lt->ctx.rsp = (void *)(stack_top - (4 * sizeof(void *)));
+ lt->ctx.rbp = (void *)(stack_top - (3 * sizeof(void *)));
+ lt->ctx.rip = func;
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* STACK_H_ */
diff --git a/examples/performance-thread/common/common.mk
b/examples/performance-thread/common/common.mk
index f6cab7718..532dbf61d 100644
--- a/examples/performance-thread/common/common.mk
+++ b/examples/performance-thread/common/common.mk
@@ -37,8 +37,12 @@
MKFILE_PATH=$(abspath $(dir $(lastword $(MAKEFILE_LIST
-VPATH := $(MKFILE_PATH) $(MKFILE_PATH)/arch/x86
+ifeq ($(CONFIG_RTE_ARCH_X86_64),y)
+ARCH_PATH += $(MKFILE_PATH)/arch/x86
+endif
+
+VPATH := $(MKFILE_PATH) $(ARCH_PATH)
SRCS-y += lthread.c lthread_sched.c lthread_cond.c lthread_tls.c
lthread_mutex.c lthread_diag.c ctx.c
-INCLUDES += -I$(MKFILE_PATH) -I$(MKFILE_PATH)/arch/x86/
+INCLUDES += -I$(MKFILE_PATH) -I$(ARCH_PATH)
diff --git a/examples/performance-thread/common/lthread.c
b/examples/performance-thread/common/lthread.c
index 062275a43..7d76c8c46 100644
--- a/examples/performance-thread/common/lthread.c
+++ b/examples/performance-thread/common/lthread.c
@@ -76,6 +76,7 @@
#include
#include
+#include
#include "lthread_api.h"
#include "lthread.h"
@@ -190,19 +191,11 @@ _lthread_init(struct lthread *lt,
*/
void _lthread_set_stack(struct lthread *lt, void *stack, size_t stack_size)
{
- char *stack_top = (char *)stack + stack_size;
- void **s = (void **)stack_top;
-
/* set stack */
lt->stack = stack;
lt->stack_size = stack_size;
- /* set initial context */
- s[-3] = NULL;
- s[-2] = (void *)lt;
- lt->ctx.rsp = (void *)(stack_top - (4 * sizeof(void *)));
- lt->ctx.rbp = (void *)(stack_top - (3 * sizeof(void *)));
- lt->ctx.rip = (void *)_lthread_exec;
+ arch_set_stack(lt, _lthread_exec);
}
/*
--
2.12.2
Re: [dpdk-dev] [PATCH] net/e1000: support MAC filters for i210 and i211 chips
On 5/18/2017 2:23 AM, Lu, Wenzhuo wrote: > Hi, > > >> -Original Message- >> From: Markus Theil [mailto:markus.th...@tu-ilmenau.de] >> Sent: Thursday, May 18, 2017 2:06 AM >> To: Lu, Wenzhuo >> Cc: dev@dpdk.org; Markus Theil >> Subject: [PATCH] net/e1000: support MAC filters for i210 and i211 chips >> >> i210 and i211 also support unicast MAC filters. >> The patch was tested on i210 based hw, for i211 support was looked up in >> the specs. >> >> Signed-off-by: Markus Theil > Acked-by: Wenzhuo Lu Applied to dpdk-next-net/master, thanks. (patch title updated to net/igb: ..) > > Thanks for this patch. >
Re: [dpdk-dev] [PATCH] net/i40e/base: fix TX error stats on VF
On 5/18/2017 4:29 AM, Wenzhuo Lu wrote:
> Unfortunately the datasheet has a mistake. The
> address of the TX error counter is wrong.
>
> Fixes: 8db9e2a1b232 ("i40e: base driver")
> CC: sta...@dpdk.org
>
> Signed-off-by: Wenzhuo Lu
Applied to dpdk-next-net/master, thanks.
[dpdk-dev] [PATCH] net/mlx5: fix wrong completion buffer size
Completion buffer size was computed wrongly, causing
completion polling to wraparound too early and miss entries.
Fixing it by using Direct Verbs to query the CQ info.
Fixes: 6218063b39a6 ("net/mlx5: refactor Rx data path")
Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
Cc: sta...@dpdk.org
Signed-off-by: Shahaf Shuler
Acked-by: Yongseok Koh
---
drivers/net/mlx5/mlx5_rxq.c | 14 +-
drivers/net/mlx5/mlx5_txq.c | 14 +-
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index 8b7823360..2a2683985 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -838,12 +838,16 @@ static inline int
rxq_setup(struct rxq_ctrl *tmpl)
{
struct ibv_cq *ibcq = tmpl->cq;
- struct mlx5_cq *cq = to_mxxx(cq, cq);
+ struct ibv_mlx5_cq_info cq_info;
struct mlx5_rwq *rwq = container_of(tmpl->wq, struct mlx5_rwq, wq);
struct rte_mbuf *(*elts)[1 << tmpl->rxq.elts_n] =
rte_calloc_socket("RXQ", 1, sizeof(*elts), 0, tmpl->socket);
- if (cq->cqe_sz != RTE_CACHE_LINE_SIZE) {
+ if (ibv_mlx5_exp_get_cq_info(ibcq, &cq_info)) {
+ ERROR("Unable to query CQ info. check your OFED.");
+ return ENOTSUP;
+ }
+ if (cq_info.cqe_size != RTE_CACHE_LINE_SIZE) {
ERROR("Wrong MLX5_CQE_SIZE environment variable value: "
"it should be set to %u", RTE_CACHE_LINE_SIZE);
return EINVAL;
@@ -851,16 +855,16 @@ rxq_setup(struct rxq_ctrl *tmpl)
if (elts == NULL)
return ENOMEM;
tmpl->rxq.rq_db = rwq->rq.db;
- tmpl->rxq.cqe_n = log2above(ibcq->cqe);
+ tmpl->rxq.cqe_n = log2above(cq_info.cqe_cnt);
tmpl->rxq.cq_ci = 0;
tmpl->rxq.rq_ci = 0;
- tmpl->rxq.cq_db = cq->dbrec;
+ tmpl->rxq.cq_db = cq_info.dbrec;
tmpl->rxq.wqes =
(volatile struct mlx5_wqe_data_seg (*)[])
(uintptr_t)rwq->rq.buff;
tmpl->rxq.cqes =
(volatile struct mlx5_cqe (*)[])
- (uintptr_t)cq->active_buf->buf;
+ (uintptr_t)cq_info.buf;
tmpl->rxq.elts = elts;
return 0;
}
diff --git a/drivers/net/mlx5/mlx5_txq.c b/drivers/net/mlx5/mlx5_txq.c
index de7e28be6..6c1387e56 100644
--- a/drivers/net/mlx5/mlx5_txq.c
+++ b/drivers/net/mlx5/mlx5_txq.c
@@ -173,23 +173,27 @@ txq_setup(struct txq_ctrl *tmpl, struct txq_ctrl
*txq_ctrl)
{
struct mlx5_qp *qp = to_mqp(tmpl->qp);
struct ibv_cq *ibcq = tmpl->cq;
- struct mlx5_cq *cq = to_mxxx(cq, cq);
+ struct ibv_mlx5_cq_info cq_info;
- if (cq->cqe_sz != RTE_CACHE_LINE_SIZE) {
+ if (ibv_mlx5_exp_get_cq_info(ibcq, &cq_info)) {
+ ERROR("Unable to query CQ info. check your OFED.");
+ return ENOTSUP;
+ }
+ if (cq_info.cqe_size != RTE_CACHE_LINE_SIZE) {
ERROR("Wrong MLX5_CQE_SIZE environment variable value: "
"it should be set to %u", RTE_CACHE_LINE_SIZE);
return EINVAL;
}
- tmpl->txq.cqe_n = log2above(ibcq->cqe);
+ tmpl->txq.cqe_n = log2above(cq_info.cqe_cnt);
tmpl->txq.qp_num_8s = qp->ctrl_seg.qp_num << 8;
tmpl->txq.wqes = qp->gen_data.sqstart;
tmpl->txq.wqe_n = log2above(qp->sq.wqe_cnt);
tmpl->txq.qp_db = &qp->gen_data.db[MLX5_SND_DBR];
tmpl->txq.bf_reg = qp->gen_data.bf->reg;
- tmpl->txq.cq_db = cq->dbrec;
+ tmpl->txq.cq_db = cq_info.dbrec;
tmpl->txq.cqes =
(volatile struct mlx5_cqe (*)[])
- (uintptr_t)cq->active_buf->buf;
+ (uintptr_t)cq_info.buf;
tmpl->txq.elts =
(struct rte_mbuf *(*)[1 << tmpl->txq.elts_n])
((uintptr_t)txq_ctrl + sizeof(*txq_ctrl));
--
2.12.0
Re: [dpdk-dev] [PATCH 2/3] net/sfc: use locally stored data for logging
On 5/17/2017 1:25 PM, Andrew Rybchenko wrote:
> Required to be able to use logging in the secondary process
> where Ethernet device pointer stored in sfc_adapter is invalid.
>
> Signed-off-by: Andrew Rybchenko
> Reviewed-by: Andy Moreton
<...>
> diff --git a/drivers/net/sfc/sfc_log.h b/drivers/net/sfc/sfc_log.h
> index d0f8921..6c43925 100644
> --- a/drivers/net/sfc/sfc_log.h
> +++ b/drivers/net/sfc/sfc_log.h
> @@ -35,18 +35,16 @@
> /* Log PMD message, automatically add prefix and \n */
> #define SFC_LOG(sa, level, ...) \
> do {\
> - const struct rte_eth_dev *_dev = (sa)->eth_dev; \
> - const struct rte_pci_device *_pci_dev = \
> - RTE_ETH_DEV_TO_PCI(_dev); \
> + const struct sfc_adapter *_sa = (sa); \
Getting following build error with clang and icc [1]. I guess that is
because "_sa" declared on both sfc_log_init() and in the macro that
function uses (SFC_LOG).
[1]
.../drivers/net/sfc/sfc_filter.c:121:2:
error: variable '_sa' is uninitialized when used within its own
initialization [-Werror,-Wuninitialized]
sfc_log_init(sa, "failed %d", rc);
^
.../drivers/net/sfc/sfc_log.h:68:12: note: expanded from macro
'sfc_log_init'
SFC_LOG(_sa, INFO, \
^
.../drivers/net/sfc/sfc_log.h:38:36: note: expanded from macro 'SFC_LOG'
const struct sfc_adapter *_sa = (sa); \
~~~^~
[dpdk-dev] [PATCH] eventdev: clarify the worker thread workflow
If the RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED capability flag
is not set indicates the device is centralized and thus needs
a dedicated scheduling thread that repeatedly calls
rte_event_schedule().
Update the worker thread code snippet to match
the description.
Signed-off-by: Jerin Jacob
---
lib/librte_eventdev/rte_eventdev.h | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/lib/librte_eventdev/rte_eventdev.h
b/lib/librte_eventdev/rte_eventdev.h
index 94284337d..a248fe90e 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -199,20 +199,6 @@
* operation. Instead, Event drivers export Poll-Mode enqueue and dequeue
* functions to applications.
*
- * An event driven based application has following typical workflow on
fastpath:
- * \code{.c}
- * while (1) {
- *
- * rte_event_schedule(dev_id);
- *
- * rte_event_dequeue(...);
- *
- * (event processing)
- *
- * rte_event_enqueue(...);
- * }
- * \endcode
- *
* The events are injected to event device through *enqueue* operation by
* event producers in the system. The typical event producers are ethdev
* subsystem for generating packet events, CPU(SW) for generating events based
@@ -237,6 +223,15 @@
* indicates the device is centralized and thus needs a dedicated scheduling
* thread that repeatedly calls rte_event_schedule().
*
+ * An event driven worker thread has following typical workflow on fastpath:
+ * \code{.c}
+ * while (1) {
+ * rte_event_dequeue_burst(...);
+ * (event processing)
+ * rte_event_enqueue_burst(...);
+ * }
+ * \endcode
+ *
*/
#ifdef __cplusplus
--
2.13.0
Re: [dpdk-dev] [PATCH] eventdev: clarify the worker thread workflow
On Thu, May 18, 2017 at 04:40:41PM +0530, Jerin Jacob wrote: > If the RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED capability flag > is not set indicates the device is centralized and thus needs > a dedicated scheduling thread that repeatedly calls > rte_event_schedule(). > > Update the worker thread code snippet to match > the description. > > Signed-off-by: Jerin Jacob > --- Acked-by: Bruce Richardson
Re: [dpdk-dev] [RFC][PATCH] vfio: allow to map other memory regions
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pawel Wodkowski > Sent: Wednesday, May 17, 2017 3:45 PM > To: dev@dpdk.org > Cc: Wodkowski, PawelX > Subject: [dpdk-dev] [RFC][PATCH] vfio: allow to map other memory regions > > Currently it is not possible to use memory that is not owned by DPDK to > perform DMA. This scenarion might be used in vhost applications (like > SPDK) where guest send its own memory table. To fill this gap provide > API to allow registering arbitrary address in VFIO container. > > Signed-off-by: Pawel Wodkowski > --- Seems to make sense to me. Presumably, such locally mapped memory would not work in multiprocess, so, obvious as it may be, this should probably be documented. Thanks, Anatoly
[dpdk-dev] [PATCH] net/igb: fix add/delete of flex filters
Before this patch, flex_filter->index was always zero when it was read
and used after rte_zmalloc. The corresponding code was therefore moved into the
add
and delete parts of the if/else statement. i210 and i211 also support
flex filters.
Signed-off-by: Markus Theil
---
drivers/net/e1000/igb_ethdev.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 43d1f5f..c8b8b0c 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -3657,7 +3657,7 @@ eth_igb_syn_filter_handle(struct rte_eth_dev *dev,
}
#define MAC_TYPE_FILTER_SUP_EXT(type)do {\
- if ((type) != e1000_82580 && (type) != e1000_i350)\
+ if ((type) != e1000_82580 && (type) != e1000_i350 && (type) !=
e1000_i210 && (type) != e1000_i211)\
return -ENOSYS; \
} while (0)
@@ -3913,10 +3913,6 @@ eth_igb_add_del_flex_filter(struct rte_eth_dev *dev,
}
wufc = E1000_READ_REG(hw, E1000_WUFC);
- if (flex_filter->index < E1000_MAX_FHFT)
- reg_off = E1000_FHFT(flex_filter->index);
- else
- reg_off = E1000_FHFT_EXT(flex_filter->index - E1000_MAX_FHFT);
if (add) {
if (eth_igb_flex_filter_lookup(&filter_info->flex_list,
@@ -3946,6 +3942,11 @@ eth_igb_add_del_flex_filter(struct rte_eth_dev *dev,
return -ENOSYS;
}
+ if (flex_filter->index < E1000_MAX_FHFT)
+ reg_off = E1000_FHFT(flex_filter->index);
+ else
+ reg_off = E1000_FHFT_EXT(flex_filter->index -
E1000_MAX_FHFT);
+
E1000_WRITE_REG(hw, E1000_WUFC, wufc | E1000_WUFC_FLEX_HQ |
(E1000_WUFC_FLX0 << flex_filter->index));
queueing = filter->len |
@@ -3974,6 +3975,11 @@ eth_igb_add_del_flex_filter(struct rte_eth_dev *dev,
return -ENOENT;
}
+ if (it->index < E1000_MAX_FHFT)
+ reg_off = E1000_FHFT(it->index);
+ else
+ reg_off = E1000_FHFT_EXT(it->index - E1000_MAX_FHFT);
+
for (i = 0; i < E1000_FHFT_SIZE_IN_DWD; i++)
E1000_WRITE_REG(hw, reg_off + i * sizeof(uint32_t), 0);
E1000_WRITE_REG(hw, E1000_WUFC, wufc &
--
2.7.4
Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library
On 5/17/2017 5:38 PM, Gaëtan Rivet wrote: > Hi Ferruh, Hi Gaetan, > > On Wed, May 17, 2017 at 05:02:50PM +0100, Ferruh Yigit wrote: >> On 5/17/2017 3:54 PM, Ananyev, Konstantin wrote: >>> Hi Ferruh, >>> Please see my comments/questions below. >> >> Thanks for review. >> >>> Thanks >>> Konstantin >> >> <...> >> >>> I think it was discussed already, but I still wonder why rte_flow_item >>> can't be used for that approach? >> >> Missed this one: >> >> Gaëtan also had same comment, copy-paste from other mail related to my >> concerns using rte_flow: >> >> " >> rte_flow is to create flow rules in PMD level, but what this library >> aims to collect flow information, independent from if underlying PMD >> implemented rte_flow or not. >> >> So issues with using rte_flow for this use case: >> 1- It may not be implemented for all PMDs (including virtual ones). >> 2- It may conflict with other rte_flow rules created by user. >> 3- It may not gather all information required. (I mean some actions >> here, count like ones are easy but rte_flow may not be so flexible to >> extract different metrics from flows) >> " > > There are two separate elements to using rte_flow in this context I think. > > One is the use of the existing actions, and as you say, this makes the > support of this library dependent on the rte_flow support in PMDs. > > The other is the expression of flows through a shared syntax. Using > flags to propose presets can be simpler, but will probably not be flexible > enough. rte_flow_items are a first-class citizen in DPDK and are > already a data type that can express flows with flexibility. As > mentioned, they are however missing a few elements to fully cover IPFIX > meters, but nothing that cannot be added I think. > > So I was probably not clear enough, but I was thinking about > supporting rte_flow_items in rte_flow_classify as the possible key > applications would use to configure their measurements. This should not > require rte_flow supports from the PMDs they would be using, only > rte_flow_item parsing from the rte_flow_classify library. > > Otherwise, DPDK will probably end up with two competing flow > representations. Additionally, it may be interesting for applications > to bind these data directly to rte_flow actions once the > classification has been analyzed. Thanks for clarification, I see now what you and Konstantin is proposing. And yes it makes sense to use rte_flow to define flows in the library, I will update the RFC. Thanks, ferruh
Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library
On 5/17/2017 5:10 PM, Ananyev, Konstantin wrote:
>>> Hi Ferruh,
>>> Please see my comments/questions below.
>>> Thanks
>>> Konstantin
>>>
+
+/**
+ * @file
+ *
+ * RTE Flow Classify Library
+ *
+ * This library provides flow record information with some measured
properties.
+ *
+ * Application can select variety of flow types based on various flow
keys.
+ *
+ * Library only maintains flow records between
rte_flow_classify_stats_get()
+ * calls and with a maximum limit.
+ *
+ * Provided flow record will be linked list rte_flow_classify_stat_xxx
+ * structure.
+ *
+ * Library is responsible from allocating and freeing memory for flow
record
+ * table. Previous table freed with next rte_flow_classify_stats_get()
call and
+ * all tables are freed with rte_flow_classify_type_reset() or
+ * rte_flow_classify_type_set(x, 0). Memory for table allocated on the
fly while
+ * creating records.
+ *
+ * A rte_flow_classify_type_set() with a valid type will register Rx/Tx
+ * callbacks and start filling flow record table.
+ * With rte_flow_classify_stats_get(), pointer sent to caller and
meanwhile
+ * library continues collecting records.
+ *
+ * Usage:
+ * - application calls rte_flow_classify_type_set() for a device
+ * - library creates Rx/Tx callbacks for packets and start filling flow
table
>>>
>>> Does it necessary to use an RX callback here?
>>> Can library provide an API like collect(port_id, input_mbuf[], pkt_num)
>>> instead?
>>> So the user would have a choice either setup a callback or call collect()
>>> directly.
>>
>> This was also comment from Morten, I will update RFC to use direct API call.
>>
>>>
+ *for that type of flow (currently only one flow type supported)
+ * - application calls rte_flow_classify_stats_get() to get pointer to
linked
+ *listed flow table. Library assigns this pointer to another value
and keeps
+ *collecting flow data. In next rte_flow_classify_stats_get(),
library first
+ *free the previous table, and pass current table to the application,
keep
+ *collecting data.
>>>
>>> Ok, but that means that you can't use stats_get() for the same type
>>> from 2 different threads without explicit synchronization?
>>
>> Correct.
>> And multiple threads shouldn't be calling this API. It doesn't store
>> previous flow data, so multiple threads calling this only can have piece
>> of information. Do you see any use case that multiple threads can call
>> this API?
>
> One example would be when you have multiple queues per port,
> managed/monitored by different cores.
> BTW, how are you going to collect the stats in that way?
>
>>
>>>
+ * - application calls rte_flow_classify_type_reset(), library
unregisters the
+ *callbacks and free all flow table data.
+ *
+ */
+
+enum rte_flow_classify_type {
+ RTE_FLOW_CLASSIFY_TYPE_GENERIC = (1 << 0),
+ RTE_FLOW_CLASSIFY_TYPE_MAX,
+};
+
+#define RTE_FLOW_CLASSIFY_TYPE_MASK = (((RTE_FLOW_CLASSIFY_TYPE_MAX - 1)
<< 1) - 1)
+
+/**
+ * Global configuration struct
+ */
+struct rte_flow_classify_config {
+ uint32_t type; /* bitwise enum rte_flow_classify_type values */
+ void *flow_table_prev;
+ uint32_t flow_table_prev_item_count;
+ void *flow_table_current;
+ uint32_t flow_table_current_item_count;
+} rte_flow_classify_config[RTE_MAX_ETHPORTS];
+
+#define RTE_FLOW_CLASSIFY_STAT_MAX UINT16_MAX
+
+/**
+ * Classification stats data struct
+ */
+struct rte_flow_classify_stat_generic {
+ struct rte_flow_classify_stat_generic *next;
+ uint32_t id;
+ uint64_t timestamp;
+
+ struct ether_addr src_mac;
+ struct ether_addr dst_mac;
+ uint32_t src_ipv4;
+ uint32_t dst_ipv4;
+ uint8_t l3_protocol_id;
+ uint16_t src_port;
+ uint16_t dst_port;
+
+ uint64_t packet_count;
+ uint64_t packet_size; /* bytes */
+};
>>>
>>> Ok, so if I understood things right, for generic type it will always
>>> classify all incoming packets by:
>>>
>>> all by absolute values, and represent results as a linked list.
>>> Is that correct, or I misunderstood your intentions here?
>>
>> Correct.
>>
>>> If so, then I see several disadvantages here:
>>> 1) It is really hard to predict what kind of stats is required for that
>>> particular cases.
>>> Let say some people would like to collect stat by ,
>>> another by , third ones by and so on.
>>> Having just one hardcoded filter doesn't seem very felxable/usable.
>>> I think you need to find a way to allow user to define what type of filter
>>> they want to apply.
>>
>> The flow type should be provided by applications, accordin
[dpdk-dev] [PATCH] ethdev: keep port_id unchanged if obtaining by name failed
Currently, 'rte_eth_dev_get_port_by_name' changes transmitted
'port_id' unconditionally. This is undocumented and misleading
behaviour as user may expect unchanged value in case of error.
Otherwise, there is no sense having both return value and
a pointer in the function.
Fixes: 9c5b8d8b9feb ("ethdev: clean port id retrieval when attaching")
Signed-off-by: Ilya Maximets
---
lib/librte_ether/rte_ethdev.c | 1 -
lib/librte_ether/rte_ethdev.h | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 83898a8..64aefdd 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -339,7 +339,6 @@ rte_eth_dev_get_port_by_name(const char *name, uint8_t
*port_id)
if (!nb_ports)
return -ENODEV;
- *port_id = RTE_MAX_ETHPORTS;
RTE_ETH_FOREACH_DEV(i) {
if (!strncmp(name,
rte_eth_dev_data[i].name, strlen(name))) {
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 0f38b45..9a19974 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -4587,7 +4587,7 @@ rte_eth_dev_l2_tunnel_offload_set(uint8_t port_id,
* @param port_id
* pointer to port identifier of the device
* @return
-* - (0) if successful.
+* - (0) if successful and port_id is filled.
* - (-ENODEV or -EINVAL) on failure.
*/
int
--
2.7.4
[dpdk-dev] [PATCH v2] net/igb: fix add/delete of flex filters
Before this patch, flex_filter->index was always zero when it was read
and used after rte_zmalloc. The corresponding code was therefore moved
into the add and delete parts of the if/else statement. i210 and i211
also support flex filters.
Signed-off-by: Markus Theil
---
drivers/net/e1000/igb_ethdev.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 43d1f5f..f090e47 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -3657,7 +3657,8 @@ eth_igb_syn_filter_handle(struct rte_eth_dev *dev,
}
#define MAC_TYPE_FILTER_SUP_EXT(type)do {\
- if ((type) != e1000_82580 && (type) != e1000_i350)\
+ if ((type) != e1000_82580 && (type) != e1000_i350 &&\
+ (type) != e1000_i210 && (type) != e1000_i211)\
return -ENOSYS; \
} while (0)
@@ -3913,10 +3914,6 @@ eth_igb_add_del_flex_filter(struct rte_eth_dev *dev,
}
wufc = E1000_READ_REG(hw, E1000_WUFC);
- if (flex_filter->index < E1000_MAX_FHFT)
- reg_off = E1000_FHFT(flex_filter->index);
- else
- reg_off = E1000_FHFT_EXT(flex_filter->index - E1000_MAX_FHFT);
if (add) {
if (eth_igb_flex_filter_lookup(&filter_info->flex_list,
@@ -3946,6 +3943,11 @@ eth_igb_add_del_flex_filter(struct rte_eth_dev *dev,
return -ENOSYS;
}
+ if (flex_filter->index < E1000_MAX_FHFT)
+ reg_off = E1000_FHFT(flex_filter->index);
+ else
+ reg_off = E1000_FHFT_EXT(flex_filter->index -
E1000_MAX_FHFT);
+
E1000_WRITE_REG(hw, E1000_WUFC, wufc | E1000_WUFC_FLEX_HQ |
(E1000_WUFC_FLX0 << flex_filter->index));
queueing = filter->len |
@@ -3974,6 +3976,11 @@ eth_igb_add_del_flex_filter(struct rte_eth_dev *dev,
return -ENOENT;
}
+ if (it->index < E1000_MAX_FHFT)
+ reg_off = E1000_FHFT(it->index);
+ else
+ reg_off = E1000_FHFT_EXT(it->index - E1000_MAX_FHFT);
+
for (i = 0; i < E1000_FHFT_SIZE_IN_DWD; i++)
E1000_WRITE_REG(hw, reg_off + i * sizeof(uint32_t), 0);
E1000_WRITE_REG(hw, E1000_WUFC, wufc &
--
2.7.4
[dpdk-dev] Defining multiple actions based on a field value for the same table lookup in ip_pipeline application
Hi all, I am trying to design a pipeline where the table lookup has to do the actions as follows: Lookup hit -> FWD to port Lookup miss -> add a table entry if incoming port was 1 drop if incoming port was 2 Is it possible to do such an implementation using ip_pipeline application? If so, how can I do that? Thanks for your reply and help. Thanks, Nidhia Varghese
Re: [dpdk-dev] [PATCH 2/3] net/sfc: use locally stored data for logging
On 05/18/2017 01:59 PM, Ferruh Yigit wrote:
On 5/17/2017 1:25 PM, Andrew Rybchenko wrote:
Required to be able to use logging in the secondary process
where Ethernet device pointer stored in sfc_adapter is invalid.
Signed-off-by: Andrew Rybchenko
Reviewed-by: Andy Moreton
<...>
diff --git a/drivers/net/sfc/sfc_log.h b/drivers/net/sfc/sfc_log.h
index d0f8921..6c43925 100644
--- a/drivers/net/sfc/sfc_log.h
+++ b/drivers/net/sfc/sfc_log.h
@@ -35,18 +35,16 @@
/* Log PMD message, automatically add prefix and \n */
#define SFC_LOG(sa, level, ...) \
do {\
- const struct rte_eth_dev *_dev = (sa)->eth_dev; \
- const struct rte_pci_device *_pci_dev = \
- RTE_ETH_DEV_TO_PCI(_dev); \
+ const struct sfc_adapter *_sa = (sa); \
Getting following build error with clang and icc [1]. I guess that is
because "_sa" declared on both sfc_log_init() and in the macro that
function uses (SFC_LOG).
Thanks, I'll fix it in v2.
[1]
.../drivers/net/sfc/sfc_filter.c:121:2:
error: variable '_sa' is uninitialized when used within its own
initialization [-Werror,-Wuninitialized]
sfc_log_init(sa, "failed %d", rc);
^
.../drivers/net/sfc/sfc_log.h:68:12: note: expanded from macro
'sfc_log_init'
SFC_LOG(_sa, INFO, \
^
.../drivers/net/sfc/sfc_log.h:38:36: note: expanded from macro 'SFC_LOG'
const struct sfc_adapter *_sa = (sa); \
~~~^~
[dpdk-dev] [PATCH v2 3/3] net/sfc: support multi-process
Signed-off-by: Andrew Rybchenko
Reviewed-by: Andy Moreton
---
v2:
- no changes
doc/guides/nics/features/sfc_efx.ini | 1 +
drivers/net/sfc/sfc.h| 11 +++
drivers/net/sfc/sfc_dp_rx.h | 1 +
drivers/net/sfc/sfc_dp_tx.h | 1 +
drivers/net/sfc/sfc_ef10_rx.c| 2 +-
drivers/net/sfc/sfc_ef10_tx.c| 5 +-
drivers/net/sfc/sfc_ethdev.c | 133 ++-
7 files changed, 148 insertions(+), 6 deletions(-)
diff --git a/doc/guides/nics/features/sfc_efx.ini
b/doc/guides/nics/features/sfc_efx.ini
index 7957b5e..1db7f67 100644
--- a/doc/guides/nics/features/sfc_efx.ini
+++ b/doc/guides/nics/features/sfc_efx.ini
@@ -28,6 +28,7 @@ Packet type parsing = Y
Basic stats = Y
Extended stats = Y
FW version = Y
+Multiprocess aware = Y
BSD nic_uio = Y
Linux UIO= Y
Linux VFIO = Y
diff --git a/drivers/net/sfc/sfc.h b/drivers/net/sfc/sfc.h
index 772a713..007ed24 100644
--- a/drivers/net/sfc/sfc.h
+++ b/drivers/net/sfc/sfc.h
@@ -225,7 +225,18 @@ struct sfc_adapter {
uint8_t rss_key[SFC_RSS_KEY_SIZE];
#endif
+ /*
+* Shared memory copy of the Rx datapath name to be used by
+* the secondary process to find Rx datapath to be used.
+*/
+ char*dp_rx_name;
const struct sfc_dp_rx *dp_rx;
+
+ /*
+* Shared memory copy of the Tx datapath name to be used by
+* the secondary process to find Rx datapath to be used.
+*/
+ char*dp_tx_name;
const struct sfc_dp_tx *dp_tx;
};
diff --git a/drivers/net/sfc/sfc_dp_rx.h b/drivers/net/sfc/sfc_dp_rx.h
index 9d05a4b..a7b8278 100644
--- a/drivers/net/sfc/sfc_dp_rx.h
+++ b/drivers/net/sfc/sfc_dp_rx.h
@@ -161,6 +161,7 @@ struct sfc_dp_rx {
unsigned intfeatures;
#define SFC_DP_RX_FEAT_SCATTER 0x1
+#define SFC_DP_RX_FEAT_MULTI_PROCESS 0x2
sfc_dp_rx_qcreate_t *qcreate;
sfc_dp_rx_qdestroy_t*qdestroy;
sfc_dp_rx_qstart_t *qstart;
diff --git a/drivers/net/sfc/sfc_dp_tx.h b/drivers/net/sfc/sfc_dp_tx.h
index 2bb9a2e..c1c3419 100644
--- a/drivers/net/sfc/sfc_dp_tx.h
+++ b/drivers/net/sfc/sfc_dp_tx.h
@@ -135,6 +135,7 @@ struct sfc_dp_tx {
#define SFC_DP_TX_FEAT_VLAN_INSERT 0x1
#define SFC_DP_TX_FEAT_TSO 0x2
#define SFC_DP_TX_FEAT_MULTI_SEG 0x4
+#define SFC_DP_TX_FEAT_MULTI_PROCESS 0x8
sfc_dp_tx_qcreate_t *qcreate;
sfc_dp_tx_qdestroy_t*qdestroy;
sfc_dp_tx_qstart_t *qstart;
diff --git a/drivers/net/sfc/sfc_ef10_rx.c b/drivers/net/sfc/sfc_ef10_rx.c
index 1484bab..60812cb 100644
--- a/drivers/net/sfc/sfc_ef10_rx.c
+++ b/drivers/net/sfc/sfc_ef10_rx.c
@@ -699,7 +699,7 @@ struct sfc_dp_rx sfc_ef10_rx = {
.type = SFC_DP_RX,
.hw_fw_caps = SFC_DP_HW_FW_CAP_EF10,
},
- .features = 0,
+ .features = SFC_DP_RX_FEAT_MULTI_PROCESS,
.qcreate= sfc_ef10_rx_qcreate,
.qdestroy = sfc_ef10_rx_qdestroy,
.qstart = sfc_ef10_rx_qstart,
diff --git a/drivers/net/sfc/sfc_ef10_tx.c b/drivers/net/sfc/sfc_ef10_tx.c
index bac9baa..5482db8 100644
--- a/drivers/net/sfc/sfc_ef10_tx.c
+++ b/drivers/net/sfc/sfc_ef10_tx.c
@@ -534,7 +534,8 @@ struct sfc_dp_tx sfc_ef10_tx = {
.type = SFC_DP_TX,
.hw_fw_caps = SFC_DP_HW_FW_CAP_EF10,
},
- .features = SFC_DP_TX_FEAT_MULTI_SEG,
+ .features = SFC_DP_TX_FEAT_MULTI_SEG |
+ SFC_DP_TX_FEAT_MULTI_PROCESS,
.qcreate= sfc_ef10_tx_qcreate,
.qdestroy = sfc_ef10_tx_qdestroy,
.qstart = sfc_ef10_tx_qstart,
@@ -549,7 +550,7 @@ struct sfc_dp_tx sfc_ef10_simple_tx = {
.name = SFC_KVARG_DATAPATH_EF10_SIMPLE,
.type = SFC_DP_TX,
},
- .features = 0,
+ .features = SFC_DP_TX_FEAT_MULTI_PROCESS,
.qcreate= sfc_ef10_tx_qcreate,
.qdestroy = sfc_ef10_tx_qdestroy,
.qstart = sfc_ef10_tx_qstart,
diff --git a/drivers/net/sfc/sfc_ethdev.c b/drivers/net/sfc/sfc_ethdev.c
index d6bba1d..0bd2de4 100644
--- a/drivers/net/sfc/sfc_ethdev.c
+++ b/drivers/net/sfc/sfc_ethdev.c
@@ -913,6 +913,10 @@ sfc_set_mc_addr_list(struct rte_eth_dev *dev, struct
ether_addr *mc_addr_set,
return -rc;
}
+/*
+ * The function is used by the secondary process as well. It must not
+ * use any process-local pointers from the adapter data.
+ */
static void
sfc_rx
[dpdk-dev] [PATCH v2 2/3] net/sfc: use locally stored data for logging
Required to be able to use logging in the secondary process
where Ethernet device pointer stored in sfc_adapter is invalid.
Signed-off-by: Andrew Rybchenko
Reviewed-by: Andy Moreton
---
v2:
- fix clang/icc build error bacause of local variable initialization
by the external variable with the same name
drivers/net/sfc/sfc.h| 2 ++
drivers/net/sfc/sfc_debug.h | 10 --
drivers/net/sfc/sfc_ethdev.c | 3 +++
drivers/net/sfc/sfc_log.h| 14 ++
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/net/sfc/sfc.h b/drivers/net/sfc/sfc.h
index 7927678..772a713 100644
--- a/drivers/net/sfc/sfc.h
+++ b/drivers/net/sfc/sfc.h
@@ -179,6 +179,8 @@ struct sfc_adapter {
*/
rte_spinlock_t lock;
enum sfc_adapter_state state;
+ struct rte_pci_addr pci_addr;
+ uint16_tport_id;
struct rte_eth_dev *eth_dev;
struct rte_kvargs *kvargs;
booldebug_init;
diff --git a/drivers/net/sfc/sfc_debug.h b/drivers/net/sfc/sfc_debug.h
index f4fe044..92eba9c 100644
--- a/drivers/net/sfc/sfc_debug.h
+++ b/drivers/net/sfc/sfc_debug.h
@@ -47,14 +47,12 @@
/* Log PMD message, automatically add prefix and \n */
#define sfc_panic(sa, fmt, args...) \
do {\
- const struct rte_eth_dev *_dev = (sa)->eth_dev; \
- const struct rte_pci_device *_pci_dev = \
- RTE_ETH_DEV_TO_PCI(_dev); \
+ const struct sfc_adapter *_sa = (sa); \
\
rte_panic("sfc " PCI_PRI_FMT " #%" PRIu8 ": " fmt "\n", \
- _pci_dev->addr.domain, _pci_dev->addr.bus,\
- _pci_dev->addr.devid, _pci_dev->addr.function,\
- _dev->data->port_id, ##args); \
+ _sa->pci_addr.domain, _sa->pci_addr.bus, \
+ _sa->pci_addr.devid, _sa->pci_addr.function, \
+ _sa->port_id, ##args);\
} while (0)
#endif /* _SFC_DEBUG_H_ */
diff --git a/drivers/net/sfc/sfc_ethdev.c b/drivers/net/sfc/sfc_ethdev.c
index e4f051a..d6bba1d 100644
--- a/drivers/net/sfc/sfc_ethdev.c
+++ b/drivers/net/sfc/sfc_ethdev.c
@@ -1513,6 +1513,9 @@ sfc_eth_dev_init(struct rte_eth_dev *dev)
sfc_register_dp();
/* Required for logging */
+ sa->pci_addr = pci_dev->addr;
+ sa->port_id = dev->data->port_id;
+
sa->eth_dev = dev;
/* Copy PCI device info to the dev->data */
diff --git a/drivers/net/sfc/sfc_log.h b/drivers/net/sfc/sfc_log.h
index d0f8921..b1a9df4 100644
--- a/drivers/net/sfc/sfc_log.h
+++ b/drivers/net/sfc/sfc_log.h
@@ -35,18 +35,16 @@
/* Log PMD message, automatically add prefix and \n */
#define SFC_LOG(sa, level, ...) \
do {\
- const struct rte_eth_dev *_dev = (sa)->eth_dev; \
- const struct rte_pci_device *_pci_dev = \
- RTE_ETH_DEV_TO_PCI(_dev); \
+ const struct sfc_adapter *__sa = (sa); \
\
RTE_LOG(level, PMD, \
RTE_FMT("sfc_efx " PCI_PRI_FMT " #%" PRIu8 ": " \
RTE_FMT_HEAD(__VA_ARGS__,) "\n",\
- _pci_dev->addr.domain, \
- _pci_dev->addr.bus, \
- _pci_dev->addr.devid, \
- _pci_dev->addr.function,\
- _dev->data->port_id,\
+ __sa->pci_addr.domain, \
+ __sa->pci_addr.bus, \
+ __sa->pci_addr.devid, \
+ __sa->pci_addr.function,\
+ __sa->port_id, \
RTE_FMT_TAIL(__VA_ARGS__,))); \
} while (0)
--
2.9.4
[dpdk-dev] [PATCH v2 1/3] net/sfc: carefully cleanup on init failure and shutdown
Signed-off-by: Andrew Rybchenko
Reviewed-by: Andy Moreton
---
v2:
- no changes
drivers/net/sfc/sfc_ethdev.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/net/sfc/sfc_ethdev.c b/drivers/net/sfc/sfc_ethdev.c
index d5583ec..e4f051a 100644
--- a/drivers/net/sfc/sfc_ethdev.c
+++ b/drivers/net/sfc/sfc_ethdev.c
@@ -1407,7 +1407,7 @@ sfc_eth_dev_set_ops(struct rte_eth_dev *dev)
"Insufficient Hw/FW capabilities to use Rx
datapath %s",
rx_name);
rc = EINVAL;
- goto fail_dp_rx;
+ goto fail_dp_rx_caps;
}
} else {
sa->dp_rx = sfc_dp_find_rx_by_caps(&sfc_dp_head, avail_caps);
@@ -1440,7 +1440,7 @@ sfc_eth_dev_set_ops(struct rte_eth_dev *dev)
"Insufficient Hw/FW capabilities to use Tx
datapath %s",
tx_name);
rc = EINVAL;
- goto fail_dp_tx;
+ goto fail_dp_tx_caps;
}
} else {
sa->dp_tx = sfc_dp_find_tx_by_caps(&sfc_dp_head, avail_caps);
@@ -1460,14 +1460,33 @@ sfc_eth_dev_set_ops(struct rte_eth_dev *dev)
return 0;
+fail_dp_tx_caps:
+ sa->dp_tx = NULL;
+
fail_dp_tx:
fail_kvarg_tx_datapath:
+fail_dp_rx_caps:
+ sa->dp_rx = NULL;
+
fail_dp_rx:
fail_kvarg_rx_datapath:
return rc;
}
static void
+sfc_eth_dev_clear_ops(struct rte_eth_dev *dev)
+{
+ struct sfc_adapter *sa = dev->data->dev_private;
+
+ dev->dev_ops = NULL;
+ dev->rx_pkt_burst = NULL;
+ dev->tx_pkt_burst = NULL;
+
+ sa->dp_tx = NULL;
+ sa->dp_rx = NULL;
+}
+
+static void
sfc_register_dp(void)
{
/* Register once */
@@ -1549,6 +1568,8 @@ sfc_eth_dev_init(struct rte_eth_dev *dev)
return 0;
fail_attach:
+ sfc_eth_dev_clear_ops(dev);
+
fail_set_ops:
sfc_unprobe(sa);
@@ -1577,16 +1598,14 @@ sfc_eth_dev_uninit(struct rte_eth_dev *dev)
sfc_adapter_lock(sa);
+ sfc_eth_dev_clear_ops(dev);
+
sfc_detach(sa);
sfc_unprobe(sa);
rte_free(dev->data->mac_addrs);
dev->data->mac_addrs = NULL;
- dev->dev_ops = NULL;
- dev->rx_pkt_burst = NULL;
- dev->tx_pkt_burst = NULL;
-
sfc_kvargs_cleanup(sa);
sfc_adapter_unlock(sa);
--
2.9.4
Re: [dpdk-dev] Defining multiple actions based on a field value for the same table lookup in ip_pipeline application
For each table a lookup hit and miss function can be registered, have a look at rte_pipeline_run(struct rte_pipeline *p) for the semantics On Thu, May 18, 2017 at 5:53 PM, Nidhia Varghese wrote: > Hi all, > > I am trying to design a pipeline where the table lookup has to do the > actions as follows: > > Lookup hit -> FWD to port > Lookup miss -> add a table entry if incoming port was 1 > drop if incoming port was 2 > > Is it possible to do such an implementation using ip_pipeline application? > If so, how can I do that? > > Thanks for your reply and help. > > Thanks, > Nidhia Varghese >
Re: [dpdk-dev] [PATCH] eventdev: define the default value for dequeue timeout
On 5/18/2017 2:18 PM, Jerin Jacob wrote:
Defining the value 0 as default value for dequeue timeout
will help the application reduce the configuration setup
if the application is interested only in default
timeout value.
Signed-off-by: Jerin Jacob
---
This patch will fix following error found in the event_pipeline RFC application
http://dpdk.org/dev/patchwork/patch/23799/ with event_octeontx HW driver.
EVENTDEV: rte_event_dev_configure() line 379: dev0 invalid
dequeue_timeout_ns=0 min_dequeue_timeout_ns=853 max_dequeue_timeout_ns=873813
---
drivers/event/octeontx/ssovf_evdev.c | 2 ++
lib/librte_eventdev/rte_eventdev.c | 5 +++--
lib/librte_eventdev/rte_eventdev.h | 1 +
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/event/octeontx/ssovf_evdev.c
b/drivers/event/octeontx/ssovf_evdev.c
index c80a44379..5499b1bf7 100644
--- a/drivers/event/octeontx/ssovf_evdev.c
+++ b/drivers/event/octeontx/ssovf_evdev.c
@@ -194,6 +194,8 @@ ssovf_configure(const struct rte_eventdev *dev)
ssovf_func_trace();
deq_tmo_ns = conf->dequeue_timeout_ns;
+ if (deq_tmo_ns == 0)
+ deq_tmo_ns = edev->min_deq_timeout_ns;
'0' should mean don't wait?
if (conf->event_dev_cfg & RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT) {
edev->is_timeout_deq = 1;
diff --git a/lib/librte_eventdev/rte_eventdev.c
b/lib/librte_eventdev/rte_eventdev.c
index 20afc3f0e..8cafffe03 100644
--- a/lib/librte_eventdev/rte_eventdev.c
+++ b/lib/librte_eventdev/rte_eventdev.c
@@ -369,9 +369,10 @@ rte_event_dev_configure(uint8_t dev_id,
/* Check dequeue_timeout_ns value is in limit */
if (!(dev_conf->event_dev_cfg & RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT))
{
- if (dev_conf->dequeue_timeout_ns < info.min_dequeue_timeout_ns
+ if (dev_conf->dequeue_timeout_ns &&
+ (dev_conf->dequeue_timeout_ns < info.min_dequeue_timeout_ns
|| dev_conf->dequeue_timeout_ns >
-info.max_dequeue_timeout_ns) {
+info.max_dequeue_timeout_ns)) {
RTE_EDEV_LOG_ERR("dev%d invalid dequeue_timeout_ns=%d"
" min_dequeue_timeout_ns=%d max_dequeue_timeout_ns=%d",
dev_id, dev_conf->dequeue_timeout_ns,
diff --git a/lib/librte_eventdev/rte_eventdev.h
b/lib/librte_eventdev/rte_eventdev.h
index 94284337d..f39fbc6b9 100644
--- a/lib/librte_eventdev/rte_eventdev.h
+++ b/lib/librte_eventdev/rte_eventdev.h
@@ -409,6 +409,7 @@ struct rte_event_dev_config {
* This value should be in the range of *min_dequeue_timeout_ns* and
* *max_dequeue_timeout_ns* which previously provided in
* rte_event_dev_info_get()
+* The value 0 is allowed, in which case, default dequeue timeout used.
* @see RTE_EVENT_DEV_CFG_PER_DEQUEUE_TIMEOUT
*/
int32_t nb_events_limit;
Re: [dpdk-dev] [RFC PATCH 00/11] net/virtio: packed ring layout
On Wed, May 17, 2017 at 01:30:21PM +0200, Jens Freimann wrote: > Hi Yuanhan, > > On Mon, May 08, 2017 at 01:02:57PM +0800, Yuanhan Liu wrote: > > On Fri, May 05, 2017 at 09:57:11AM -0400, Jens Freimann wrote: > > > I'm implementing the receive path now to eventually get some benchmark > > > results for that as well (Patches not included yet) > > > > Good to know. Any progress? I'm asking because that was also my plan for > > this week: make Rx work. I haven't started it though. > > just curious if you already had a chance to work on this? Yes, I made it work this Tue. I will try to share it tomorrow. I was on vacation though. --yliu
Re: [dpdk-dev] [PATCH v2] kni: add new mbuf in alloc_q only based on its empty slots
On Tuesday 16 May 2017 10:45 PM, Ferruh Yigit wrote:
On 5/11/2017 12:51 PM, Gowrishankar wrote:
From: Gowrishankar Muthukrishnan
In kni_allocate_mbufs(), we attempt to add max_burst (32) count of mbuf
always into alloc_q, which is excessively leading too many rte_pktmbuf_
free() when alloc_q is contending at high packet rate (for eg 10Gig data).
In a situation when alloc_q fifo can only accommodate very few (or zero)
mbuf, create only what needed and add in fifo.
I remember I have tried similar, also tried allocating amount of
nb_packets read from kernel, both produced worse performance.
Can you please share your before/after performance numbers?
Sure Ferruh, please find below comparison of call counts I set at two places
along with additional stat on kni egress for more than one packet in txq
burst read,
as in pseudo code below:
@@ -589,8 +592,12 @@ rte_kni_rx_burst(struct rte_kni *kni, struct
rte_mbuf **mbufs, unsigned num)
unsigned ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);
/* If buffers removed, allocate mbufs and then put them
into alloc_q */
if (ret) {
++alloc_call;
if (ret > 1)
alloc_call_mt1tx += ret;
kni_allocate_mbufs(kni);
}
return ret;
}
@@ -659,6 +666,7 @@ kni_allocate_mbufs(struct rte_kni *kni)
if (ret >= 0 && ret < i && ret < MAX_MBUF_BURST_NUM) {
int j;
freembuf_call += (i-ret);
for (j = ret; j < i; j++)
rte_pktmbuf_free(pkts[j]);
kni_allocate_mbufs() called within rte_kni_rx_burst() if any packet
received from kernel. If there is a heavy traffic, kernel will always
consume the alloc_q before this function called and this function will
fill it back. So there shouldn't be much cases that alloc_q fifo already
full.
Perhaps this can happen if application burst Rx from kernel in a number
less than 32, but fifo filled with fixed 32mbufs, is this your case?
I think some resemblance to this case based on below stats. W/o patch,
application
would spend its most of processing in freeing mbufs right ?.
Can you measure number of times rte_pktmbuf_free() called because of
alloc_q is full?
I have sampled below data in x86_64 for KNI on ixgbe pmd. iperf server
runs on
remote interface connecting PMD and iperf client runs on KNI interface,
so as to
create more egress from KNI into DPDK (w/o and with this patch) for 1MB and
100MB data. rx and tx stats are from kni app (USR1).
100MB w/o patch 1.28Gbps
rx txalloc_call alloc_call_mt1tx freembuf_call
3933 72464 51042 42472 1560540
1MB w/o patch 204Mbps
rx tx alloc_call alloc_call_mt1tx freembuf_call
84 734566330 17378
100MB w/ patch 1.23Gbps
rx txalloc_call alloc_call_mt1tx freembuf_call
4258 72466 72466 0 0
1MB w/ patch 203Mbps
rx tx alloc_call alloc_call_mt1tx freembuf_call
76 7347332 0
With patch, KNI egress on txq seems to be almost only one packet at a time
(and in 1MB test, a rare instance of more than 2 packets seen even
though it is
burst read). Also, as it is one mbuf consumed by module and added by lib at
a time, rte_pktmbuf_free is not called at all, due to right amount (1 or 2)
of mbufs enqueued in alloc_q.
This controlled enqueue on alloc_q avoids nw stall for i40e in ppc64le.
Could you
please check if i40e is able to handle data at order of 10GiB in your
arch, as I see
that, network stalls at some random point w/o this patch.
Thanks,
Gowrishankar
With this patch, we could stop random network stall in KNI at higher packet
rate (eg 1G or 10G data between vEth0 and PMD) sufficiently exhausting
alloc_q on above condition. I tested i40e PMD for this purpose in ppc64le.
If stall happens from NIC to kernel, this is kernel receive path, and
alloc_q is in kernel transmit path.
Changes:
v2 - alloc_q free count calculation corrected.
line wrap fixed for commit message.
Signed-off-by: Gowrishankar Muthukrishnan
---
lib/librte_kni/rte_kni.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index c3f9208..9c5d485 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -624,6 +624,7 @@ struct rte_kni *
int i, ret;
struct rte_mbuf *pkts[MAX_MBUF_BURST_NUM];
void *phys[MAX_MBUF_BURST_NUM];
+ int allocq_free;
RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, pool) !=
offsetof(struct rte_kni_mbuf, pool));
@@ -646,7 +647,9 @@ struct rte_kni *
return;
}
- for (i = 0; i < MAX_MBUF_BURST_NUM; i++) {
+ allocq_free = (kni->alloc_q->read - kni->alloc_q->write - 1) \
+ & (MAX_MBUF_BURST_NUM - 1);
+ for (i
[dpdk-dev] [RFC v2] flow_classify: add librte_flow_classify library
Signed-off-by: Ferruh Yigit --- Cc: Bernard Iremonger Cc: Adrien Mazarguil RFC v2: * prefer user called functions to callbacks * use rte_flow to define flows and actions --- config/common_base | 5 + doc/api/doxy-api-index.md | 1 + doc/api/doxy-api.conf | 1 + doc/guides/rel_notes/release_17_08.rst | 1 + lib/Makefile | 2 + lib/librte_flow_classify/Makefile | 50 lib/librte_flow_classify/rte_flow_classify.c | 72 lib/librte_flow_classify/rte_flow_classify.h | 129 + .../rte_flow_classify_version.map | 7 ++ mk/rte.app.mk | 1 + 10 files changed, 269 insertions(+) create mode 100644 lib/librte_flow_classify/Makefile create mode 100644 lib/librte_flow_classify/rte_flow_classify.c create mode 100644 lib/librte_flow_classify/rte_flow_classify.h create mode 100644 lib/librte_flow_classify/rte_flow_classify_version.map diff --git a/config/common_base b/config/common_base index 8907bea..3a7e73a 100644 --- a/config/common_base +++ b/config/common_base @@ -651,6 +651,11 @@ CONFIG_RTE_LIBRTE_IP_FRAG_TBL_STAT=n CONFIG_RTE_LIBRTE_METER=y # +# Compile librte_classify +# +CONFIG_RTE_LIBRTE_FLOW_CLASSIFY=y + +# # Compile librte_sched # CONFIG_RTE_LIBRTE_SCHED=y diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index f5f1f19..d18c2b6 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -98,6 +98,7 @@ There are many libraries, so their headers may be grouped by topics: [LPM IPv4 route] (@ref rte_lpm.h), [LPM IPv6 route] (@ref rte_lpm6.h), [ACL](@ref rte_acl.h), + [flow_classify] (@ref rte_flow_classify.h), [EFD](@ref rte_efd.h) - **QoS**: diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf index ca9194f..94f3d0f 100644 --- a/doc/api/doxy-api.conf +++ b/doc/api/doxy-api.conf @@ -46,6 +46,7 @@ INPUT = doc/api/doxy-api-index.md \ lib/librte_efd \ lib/librte_ether \ lib/librte_eventdev \ + lib/librte_flow_classify \ lib/librte_hash \ lib/librte_ip_frag \ lib/librte_jobstats \ diff --git a/doc/guides/rel_notes/release_17_08.rst b/doc/guides/rel_notes/release_17_08.rst index 74aae10..6362bb2 100644 --- a/doc/guides/rel_notes/release_17_08.rst +++ b/doc/guides/rel_notes/release_17_08.rst @@ -152,6 +152,7 @@ The libraries prepended with a plus sign were incremented in this version. librte_distributor.so.1 librte_eal.so.4 librte_ethdev.so.6 + + librte_flow_classify.so.1 librte_hash.so.2 librte_ip_frag.so.1 librte_jobstats.so.1 diff --git a/lib/Makefile b/lib/Makefile index 07e1fd0..e63cd61 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -80,6 +80,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_POWER) += librte_power DEPDIRS-librte_power := librte_eal DIRS-$(CONFIG_RTE_LIBRTE_METER) += librte_meter DEPDIRS-librte_meter := librte_eal +DIRS-$(CONFIG_RTE_LIBRTE_FLOW_CLASSIFY) += librte_flow_classify +DEPDIRS-librte_flow_classify := librte_eal librte_ether librte_net DIRS-$(CONFIG_RTE_LIBRTE_SCHED) += librte_sched DEPDIRS-librte_sched := librte_eal librte_mempool librte_mbuf librte_net DEPDIRS-librte_sched += librte_timer diff --git a/lib/librte_flow_classify/Makefile b/lib/librte_flow_classify/Makefile new file mode 100644 index 000..c57e9a3 --- /dev/null +++ b/lib/librte_flow_classify/Makefile @@ -0,0 +1,50 @@ +# BSD LICENSE +# +# Copyright(c) 2017 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, IND
[dpdk-dev] [RFC v2] Flow classification library
DPDK works with packets, but some network administration tools works based on flow information. This library is suggested to provide helper API to convert packet based information to the flow records. Basically the library consist of a single API that gets packets, flow definition and action as parameter and provides flow stats based on action. Application should call the API for all received packets. Library header file has more comments on how library works and provided APIs. Packets to flow conversion will cause performance drop, that is why conversion done on demand by an API call provided by this library. Initial implementation in mind is to provide support for IPFIX metering process but library planned to be as generic as possible. And flow information provided by this library is missing to implement full IPFIX features, but this is planned to be initial step. Flows are defined using rte_flow, also measurements (actions) are provided by rte_flow. To support more IPFIX measurements, the implementation may require extending rte_flow addition to implementing this library. Since both flows and action defined by rte_flow, it is possible to consider this library as rte_flow software fallback. And in case the underlying hardware supports the provided flow and action, in implementation details this library may prefer to use hardware support to get the requested stats, for the actions that are not supported by hardware this library will implement the ways to get the stats. It will be more beneficial to shape this library to cover more use cases, please feel free to comment on possible other use case and desired functionalities. Changes to previous version of the RFC: v2: * library uses rte_flow to define flows and action. * no more callbacks used, user should call API in poll mode for flow stats. * library no more maintain any flow data, all flow related stats returned by API call and forgotten. Thanks, ferruh cc: John McNamara cc: Maryam Tahhan Ferruh Yigit (1): flow_classify: add librte_flow_classify library config/common_base | 5 + doc/api/doxy-api-index.md | 1 + doc/api/doxy-api.conf | 1 + doc/guides/rel_notes/release_17_08.rst | 1 + lib/Makefile | 2 + lib/librte_flow_classify/Makefile | 50 lib/librte_flow_classify/rte_flow_classify.c | 72 lib/librte_flow_classify/rte_flow_classify.h | 129 + .../rte_flow_classify_version.map | 7 ++ mk/rte.app.mk | 1 + 10 files changed, 269 insertions(+) create mode 100644 lib/librte_flow_classify/Makefile create mode 100644 lib/librte_flow_classify/rte_flow_classify.c create mode 100644 lib/librte_flow_classify/rte_flow_classify.h create mode 100644 lib/librte_flow_classify/rte_flow_classify_version.map -- 2.9.3
Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library
18/05/2017 13:33, Ferruh Yigit: > On 5/17/2017 5:38 PM, Gaëtan Rivet wrote: > > The other is the expression of flows through a shared syntax. Using > > flags to propose presets can be simpler, but will probably not be flexible > > enough. rte_flow_items are a first-class citizen in DPDK and are > > already a data type that can express flows with flexibility. As > > mentioned, they are however missing a few elements to fully cover IPFIX > > meters, but nothing that cannot be added I think. > > > > So I was probably not clear enough, but I was thinking about > > supporting rte_flow_items in rte_flow_classify as the possible key > > applications would use to configure their measurements. This should not > > require rte_flow supports from the PMDs they would be using, only > > rte_flow_item parsing from the rte_flow_classify library. > > > > Otherwise, DPDK will probably end up with two competing flow > > representations. Additionally, it may be interesting for applications > > to bind these data directly to rte_flow actions once the > > classification has been analyzed. > > Thanks for clarification, I see now what you and Konstantin is proposing. > > And yes it makes sense to use rte_flow to define flows in the library, I > will update the RFC. Does it mean that rte_flow.h must be moved from ethdev to this new flow library? Or will it depend of ethdev?
[dpdk-dev] [PATCH] examples/exception_path: add FreeBSD support
Signed-off-by: Tiwei Bie
---
examples/exception_path/Makefile | 9 -
examples/exception_path/main.c | 28 +++-
2 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/examples/exception_path/Makefile b/examples/exception_path/Makefile
index 4b6e07175..76706c124 100644
--- a/examples/exception_path/Makefile
+++ b/examples/exception_path/Makefile
@@ -38,13 +38,6 @@ RTE_TARGET ?= x86_64-native-linuxapp-gcc
include $(RTE_SDK)/mk/rte.vars.mk
-ifneq ($(CONFIG_RTE_EXEC_ENV),"linuxapp")
-$(info This application can only operate in a linuxapp environment, \
-please change the definition of the RTE_TARGET environment variable)
-all:
-clean:
-else
-
# binary name
APP = exception_path
@@ -55,5 +48,3 @@ CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
include $(RTE_SDK)/mk/rte.extapp.mk
-
-endif
diff --git a/examples/exception_path/main.c b/examples/exception_path/main.c
index 89bf1cc06..fe30e0703 100644
--- a/examples/exception_path/main.c
+++ b/examples/exception_path/main.c
@@ -42,8 +42,10 @@
#include
#include
-#include
+#include
+#ifdef RTE_EXEC_ENV_LINUXAPP
#include
+#endif
#include
#include
#include
@@ -182,6 +184,7 @@ signal_handler(int signum)
}
}
+#ifdef RTE_EXEC_ENV_LINUXAPP
/*
* Create a tap network interface, or use existing one with same name.
* If name[0]='\0' then a name is automatically assigned and returned in name.
@@ -214,6 +217,29 @@ static int tap_create(char *name)
return fd;
}
+#else
+/*
+ * Find a free tap network interface, or create a new one.
+ * The name is automatically assigned and returned in name.
+ */
+static int tap_create(char *name)
+{
+ int i, fd = -1;
+ char devname[PATH_MAX];
+
+ for (i = 0; i < 255; i++) {
+ snprintf(devname, sizeof(devname), "/dev/tap%d", i);
+ fd = open(devname, O_RDWR);
+ if (fd >= 0 || errno != EBUSY)
+ break;
+ }
+
+ if (name)
+ snprintf(name, IFNAMSIZ, "tap%d", i);
+
+ return fd;
+}
+#endif
/* Main processing loop */
static int
--
2.12.1
Re: [dpdk-dev] [PATCH 3/6] eal/arm64: rte pause implementation for arm64
On 18 May 2017 at 18:16, Jerin Jacob wrote:
> -Original Message-
>> Date: Thu, 18 May 2017 17:40:58 +0800
>> From: Jianbo Liu
>> To: Jerin Jacob
>> Cc: dev@dpdk.org, tho...@monjalon.net, Jan Viktorin
>>
>> Subject: Re: [dpdk-dev] [PATCH 3/6] eal/arm64: rte pause implementation for
>> arm64
>>
>> On 11 May 2017 at 18:10, Jerin Jacob wrote:
>> > CC: Jianbo Liu
>> > Signed-off-by: Jerin Jacob
>> > ---
>> > lib/librte_eal/common/include/arch/arm/rte_pause.h | 4 ++
>> > .../common/include/arch/arm/rte_pause_64.h | 55
>> > ++
>> > 2 files changed, 59 insertions(+)
>> > create mode 100644 lib/librte_eal/common/include/arch/arm/rte_pause_64.h
>> >
>> > diff --git a/lib/librte_eal/common/include/arch/arm/rte_pause.h
>> > b/lib/librte_eal/common/include/arch/arm/rte_pause.h
>> > index 0fe88aba9..9b79405e6 100644
>> > --- a/lib/librte_eal/common/include/arch/arm/rte_pause.h
>> > +++ b/lib/librte_eal/common/include/arch/arm/rte_pause.h
>> > @@ -37,7 +37,11 @@
>> > extern "C" {
>> > #endif
>> >
>> > +#ifdef RTE_ARCH_64
>> > +#include
>> > +#else
>> > #include
>> > +#endif
>> >
>> > #ifdef __cplusplus
>> > }
>> > diff --git a/lib/librte_eal/common/include/arch/arm/rte_pause_64.h
>> > b/lib/librte_eal/common/include/arch/arm/rte_pause_64.h
>> > new file mode 100644
>> > index 0..cae996de8
>> > --- /dev/null
>> > +++ b/lib/librte_eal/common/include/arch/arm/rte_pause_64.h
>> > @@ -0,0 +1,55 @@
>> > +/*
>> > + * BSD LICENSE
>> > + *
>> > + * Copyright(c) 2017 Cavium. All rights reserved.
>> > + *
>> > + * Redistribution and use in source and binary forms, with or without
>> > + * modification, are permitted provided that the following conditions
>> > + * are met:
>> > + *
>> > + * * Redistributions of source code must retain the above copyright
>> > + * notice, this list of conditions and the following disclaimer.
>> > + * * Redistributions in binary form must reproduce the above copyright
>> > + * notice, this list of conditions and the following disclaimer in
>> > + * the documentation and/or other materials provided with the
>> > + * distribution.
>> > + * * Neither the name of Cavium 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.
>> > + */
>> > +
>> > +#ifndef _RTE_PAUSE_ARM64_H_
>> > +#define _RTE_PAUSE_ARM64_H_
>> > +
>> > +#ifdef __cplusplus
>> > +extern "C" {
>> > +#endif
>> > +
>> > +#include
>> > +#include "generic/rte_pause.h"
>> > +
>> > +static inline void rte_pause(void)
>> > +{
>> > + /* YIELD hints the CPU to switch to another thread if possible
>> > +* and executes as a NOP otherwise.
>>
>> I think you can remove the second line if you are trying to explain
>> what YIELD instruction is.
>> And I wonder if it can save power as rte_thread is bounded to certain
>> core and always polling while YIELD is only a hint instruction.
>
> AFAIK, It is HW thread not software OS thread.ie Simultaneous Multi-Threading
> (SMT)
> or Hyper threading.
>
I read aarch64 ISA, and thought it's software thread.
It's likely each partner can extend more on its own implementation.
> For example, Cavium 99xx has 4 HW threads per physical core.
>
> I agree on comment. I think, I can remove the comment as YIELD is just a hint
> and varies based on arm64 implementation. Will fix it v2.
>
OK
>>
>> > +*/
>> > + asm volatile("yield" ::: "memory");
>> > +}
>> > +
>> > +#ifdef __cplusplus
>> > +}
>> > +#endif
>> > +
>> > +#endif /* _RTE_PAUSE_ARM64_H_ */
>> > --
>> > 2.12.2
>> >
Re: [dpdk-dev] Defining multiple actions based on a field value for the same table lookup in ip_pipeline application
Thanks for your reply Shyam. Yes, I went through it. But my doubt is whether it is possible to define two different miss actions based on some decision criteria(input port in my case). Miss ->Case 1: Add entry to table if portid = 1 ->Case 2: Drop if portid = 2 On Thu, May 18, 2017 at 7:34 PM, Shyam Shrivastav < shrivastav.sh...@gmail.com> wrote: > For each table a lookup hit and miss function can be registered, have a > look at > rte_pipeline_run(struct rte_pipeline *p) for the semantics > Thanks, Nidhia Varghese
Re: [dpdk-dev] Defining multiple actions based on a field value for the same table lookup in ip_pipeline application
That can be done in the same miss function as I understand, if (condition1)
{} else {}
On Fri, May 19, 2017 at 10:53 AM, Nidhia Varghese <
nidhiavarghes...@gmail.com> wrote:
> Thanks for your reply Shyam.
> Yes, I went through it. But my doubt is whether it is possible to define
> two different miss actions based on some decision criteria(input port in my
> case).
> Miss ->Case 1: Add entry to table if portid = 1
> ->Case 2: Drop if portid = 2
>
> On Thu, May 18, 2017 at 7:34 PM, Shyam Shrivastav <
> shrivastav.sh...@gmail.com> wrote:
>
>> For each table a lookup hit and miss function can be registered, have a
>> look at
>> rte_pipeline_run(struct rte_pipeline *p) for the semantics
>>
>
> Thanks,
> Nidhia Varghese
>
