Message ID | 1449154976-16501-3-git-send-email-jianbo.liu@linaro.org (mailing list archive) |
---|---|
State | Accepted, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 28DE58E6E; Thu, 3 Dec 2015 16:03:15 +0100 (CET) Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 2F92B8E75 for <dev@dpdk.org>; Thu, 3 Dec 2015 16:03:13 +0100 (CET) Received: by wmvv187 with SMTP id v187so31500398wmv.1 for <dev@dpdk.org>; Thu, 03 Dec 2015 07:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=gkImaqa9WC1Vj48ofltOa6rf0HCJe6ot1Fcva4UmV2U=; b=NmZx6SRPdseWsX099j+sZjd/UT01SczgKiCVouKvEhXg6Xm+yXUXeQ4UcOjNFwW/kt rOrJ9nHfWZuHxov/nl3bwRWE2x9efqdljtwzVQhnN4GrUpMnfTg1HUzMG+VSqKXXxoeZ UMz1Ttf0t9wXBJge7u/mlVgUTOdTW+vRuYSO0ErwmvG2Dvb0H4Bm8IG5vBQcKzuggVk/ +v4xhKAG4BnTRS37hQ0dI91YKsc0fKgaYc3NsxqSmYS74tHc1C57CSsy6VDQsWFsNBc4 RXzLD3T12az3IJT5y9N9YAs/dwqUONorVSZz4YHGuCOsCJpiyr+SgxPrlwCvJvhskq4i 2+QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=gkImaqa9WC1Vj48ofltOa6rf0HCJe6ot1Fcva4UmV2U=; b=bvLRZTshJ4MAwqnPUx1CdIDuydSaNlGPMtd5ttWD9QFgDo/UGR1uFgasBIl9EwaCQW syRcasgQ/8ZrOAi2KV36crNRtSoz2ZO5QFWE9GnHR9YmjVyaCQUkGlvZPEbLBw/g31lw yWFQbVL3v7iAgI8h49aLNKNQ07ehG8XSsH+Iq5RzWEypq/aHHOWBpIOqLATt8axBuxUN zp//aIIQmNpYLr7hHyLZDOI0DuZhmKvbGk0emTstgIdPDurkxHUvJ3WyYe8/60/WBlWg qYajOR8XMWkEiOVeckoBwOlOSRJRQK2Gq7D5jbWtkBDgrh+jcIV4xpSssDcZMylK3Z9B JiwA== X-Gm-Message-State: ALoCoQlogdp/BlhJxGyXztDm4lIktfSpXZ+xk4dmeqIWkWmGiGv+MNYGnn/DmZT5bF3/tJ04c5ci X-Received: by 10.195.11.233 with SMTP id el9mr11464860wjd.145.1449154992996; Thu, 03 Dec 2015 07:03:12 -0800 (PST) Received: from localhost ([112.65.63.39]) by smtp.gmail.com with ESMTPSA id n7sm8292386wmf.21.2015.12.03.07.03.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2015 07:03:12 -0800 (PST) From: Jianbo Liu <jianbo.liu@linaro.org> To: dev@dpdk.org Date: Thu, 3 Dec 2015 23:02:55 +0800 Message-Id: <1449154976-16501-3-git-send-email-jianbo.liu@linaro.org> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1449154976-16501-1-git-send-email-jianbo.liu@linaro.org> References: <1448995276-9599-1-git-send-email-jianbo.liu@linaro.org> <1449154976-16501-1-git-send-email-jianbo.liu@linaro.org> Subject: [dpdk-dev] [PATCH v2 2/3] eal/acl: enable acl for armv7-a X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Jianbo Liu
Dec. 3, 2015, 3:02 p.m. UTC
Implement vqtbl1q_u8 intrinsic function, which is not support in armv7-a.
Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
---
config/defconfig_arm-armv7a-linuxapp-gcc | 1 -
lib/librte_acl/Makefile | 2 +-
lib/librte_acl/rte_acl.c | 5 ++++-
lib/librte_eal/common/include/arch/arm/rte_vect.h | 23 +++++++++++++++++++++++
4 files changed, 28 insertions(+), 3 deletions(-)
Comments
On Thu, Dec 03, 2015 at 11:02:55PM +0800, Jianbo Liu wrote: > Implement vqtbl1q_u8 intrinsic function, which is not support in armv7-a. > > Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org> Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > --- > config/defconfig_arm-armv7a-linuxapp-gcc | 1 - > lib/librte_acl/Makefile | 2 +- > lib/librte_acl/rte_acl.c | 5 ++++- > lib/librte_eal/common/include/arch/arm/rte_vect.h | 23 +++++++++++++++++++++++ > 4 files changed, 28 insertions(+), 3 deletions(-) > > diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc > index 9924ff9..cbebd64 100644 > --- a/config/defconfig_arm-armv7a-linuxapp-gcc > +++ b/config/defconfig_arm-armv7a-linuxapp-gcc > @@ -53,7 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n > CONFIG_RTE_EAL_IGB_UIO=n > > # fails to compile on ARM > -CONFIG_RTE_LIBRTE_ACL=n > CONFIG_RTE_LIBRTE_LPM=n > CONFIG_RTE_LIBRTE_TABLE=n > CONFIG_RTE_LIBRTE_PIPELINE=n > diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile > index 897237d..2e394c9 100644 > --- a/lib/librte_acl/Makefile > +++ b/lib/librte_acl/Makefile > @@ -49,7 +49,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_bld.c > SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_gen.c > SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_scalar.c > > -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) > +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) > SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_neon.c > CFLAGS_acl_run_neon.o += -flax-vector-conversions -Wno-maybe-uninitialized > else > diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c > index e2fdebd..4ba9786 100644 > --- a/lib/librte_acl/rte_acl.c > +++ b/lib/librte_acl/rte_acl.c > @@ -114,8 +114,11 @@ rte_acl_init(void) > { > enum rte_acl_classify_alg alg = RTE_ACL_CLASSIFY_DEFAULT; > > -#ifdef RTE_ARCH_ARM64 > +#if defined(RTE_ARCH_ARM64) > alg = RTE_ACL_CLASSIFY_NEON; > +#elif defined(RTE_ARCH_ARM) > + if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON)) > + alg = RTE_ACL_CLASSIFY_NEON; > #else > #ifdef CC_AVX2_SUPPORT > if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2)) > diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h > index 21cdb4d..a33c054 100644 > --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h > +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h > @@ -53,6 +53,29 @@ typedef union rte_xmm { > double pd[XMM_SIZE / sizeof(double)]; > } __attribute__((aligned(16))) rte_xmm_t; > > +#ifdef RTE_ARCH_ARM > +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ > +static __inline uint8x16_t > +vqtbl1q_u8(uint8x16_t a, uint8x16_t b) > +{ > + uint8_t i, pos; > + rte_xmm_t rte_a, rte_b, rte_ret; > + > + vst1q_u8(rte_a.u8, a); > + vst1q_u8(rte_b.u8, b); > + > + for (i = 0; i < 16; i++) { > + pos = rte_b.u8[i]; > + if (pos < 16) > + rte_ret.u8[i] = rte_a.u8[pos]; > + else > + rte_ret.u8[i] = 0; > + } > + > + return vld1q_u8(rte_ret.u8); > +} > +#endif > + > #ifdef __cplusplus > } > #endif > -- > 1.8.3.1 >
2015-12-03 23:02, Jianbo Liu: > -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) > +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) [...] > +#ifdef RTE_ARCH_ARM > +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ I'm convinced there is a good reason why ARMv8 is also called ARCH_ARM64, and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why? Is ARCH_ARM32 or ARCH_ARMv7 too simple? Is it possible to have a 32-bit ARMv8?
On 8 December 2015 at 09:18, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > 2015-12-03 23:02, Jianbo Liu: >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) >> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) > [...] >> +#ifdef RTE_ARCH_ARM >> +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ > > I'm convinced there is a good reason why ARMv8 is also called ARCH_ARM64, > and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why? > https://lkml.org/lkml/2012/7/15/133 > Is ARCH_ARM32 or ARCH_ARMv7 too simple? > Is it possible to have a 32-bit ARMv8? Yes, ARMv8-R/M
2015-12-08 09:50, Jianbo Liu: > On 8 December 2015 at 09:18, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > > 2015-12-03 23:02, Jianbo Liu: > >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) > >> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) > > [...] > >> +#ifdef RTE_ARCH_ARM > >> +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ > > > > I'm convinced there is a good reason why ARMv8 is also called ARCH_ARM64, > > and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why? > > > https://lkml.org/lkml/2012/7/15/133 > > > Is ARCH_ARM32 or ARCH_ARMv7 too simple? > > Is it possible to have a 32-bit ARMv8? > Yes, ARMv8-R/M So what does mean CONFIG_RTE_ARCH_ARM? ARMv7? ARM32? Please consider a renaming.
On 8 December 2015 at 10:23, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > 2015-12-08 09:50, Jianbo Liu: >> On 8 December 2015 at 09:18, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: >> > 2015-12-03 23:02, Jianbo Liu: >> >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) >> >> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) >> > [...] >> >> +#ifdef RTE_ARCH_ARM >> >> +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ >> > >> > I'm convinced there is a good reason why ARMv8 is also called ARCH_ARM64, >> > and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why? >> > >> https://lkml.org/lkml/2012/7/15/133 >> >> > Is ARCH_ARM32 or ARCH_ARMv7 too simple? >> > Is it possible to have a 32-bit ARMv8? >> Yes, ARMv8-R/M > > So what does mean CONFIG_RTE_ARCH_ARM? > ARMv7? ARM32? > Please consider a renaming. I'd rather not renaming becase it can be both ARMv7 and AARCH32, which are ISA compatibility. If further differentiation is needed, CONFIG_RTE_ARCH_ARMv7 is added in the config, just like Jan Viktorin did.
2015-12-08 15:56, Jianbo Liu: > On 8 December 2015 at 10:23, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > > 2015-12-08 09:50, Jianbo Liu: > >> On 8 December 2015 at 09:18, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > >> > 2015-12-03 23:02, Jianbo Liu: > >> >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) > >> >> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) > >> > [...] > >> >> +#ifdef RTE_ARCH_ARM > >> >> +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ > >> > > >> > I'm convinced there is a good reason why ARMv8 is also called ARCH_ARM64, > >> > and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why? > >> > > >> https://lkml.org/lkml/2012/7/15/133 > >> > >> > Is ARCH_ARM32 or ARCH_ARMv7 too simple? > >> > Is it possible to have a 32-bit ARMv8? > >> Yes, ARMv8-R/M > > > > So what does mean CONFIG_RTE_ARCH_ARM? > > ARMv7? ARM32? > > Please consider a renaming. > > I'd rather not renaming becase it can be both ARMv7 and AARCH32, which > are ISA compatibility. > If further differentiation is needed, CONFIG_RTE_ARCH_ARMv7 is added > in the config, just like Jan Viktorin did. I don't understand. You say CONFIG_RTE_ARCH_ARM is for ARMv7 and AARCH32, right? Both are 32-bit right? Why not rename it to CONFIG_RTE_ARCH_ARM32?
On 8 December 2015 at 18:03, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > 2015-12-08 15:56, Jianbo Liu: >> On 8 December 2015 at 10:23, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: >> > 2015-12-08 09:50, Jianbo Liu: >> >> On 8 December 2015 at 09:18, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: >> >> > 2015-12-03 23:02, Jianbo Liu: >> >> >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) >> >> >> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) >> >> > [...] >> >> >> +#ifdef RTE_ARCH_ARM >> >> >> +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ >> >> > >> >> > I'm convinced there is a good reason why ARMv8 is also called ARCH_ARM64, >> >> > and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why? >> >> > >> >> https://lkml.org/lkml/2012/7/15/133 >> >> >> >> > Is ARCH_ARM32 or ARCH_ARMv7 too simple? >> >> > Is it possible to have a 32-bit ARMv8? >> >> Yes, ARMv8-R/M >> > >> > So what does mean CONFIG_RTE_ARCH_ARM? >> > ARMv7? ARM32? >> > Please consider a renaming. >> >> I'd rather not renaming becase it can be both ARMv7 and AARCH32, which >> are ISA compatibility. >> If further differentiation is needed, CONFIG_RTE_ARCH_ARMv7 is added >> in the config, just like Jan Viktorin did. > > I don't understand. > You say CONFIG_RTE_ARCH_ARM is for ARMv7 and AARCH32, right? > Both are 32-bit right? > Why not rename it to CONFIG_RTE_ARCH_ARM32? I understand that you want to make the naming more clear. But arm/arm64 are used in Linux kernel, I think it's better to stay the same.
Původní zpráva Od: Thomas Monjalon Odesláno: úterý, 8. prosince 2015 11:04 Komu: Jianbo Liu Kopie: dev@dpdk.org; Jan Viktorin; Jerin Jacob Předmět: Re: [dpdk-dev] [PATCH v2 2/3] eal/acl: enable acl for armv7-a 2015-12-08 15:56, Jianbo Liu: > On 8 December 2015 at 10:23, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > > 2015-12-08 09:50, Jianbo Liu: > >> On 8 December 2015 at 09:18, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > >> > 2015-12-03 23:02, Jianbo Liu: > >> >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) > >> >> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) > >> > [...] > >> >> +#ifdef RTE_ARCH_ARM > >> >> +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ > >> > > >> > I'm convinced there is a good reason why ARMv8 is also called ARCH_ARM64, > >> > and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why? > >> > > >> https://lkml.org/lkml/2012/7/15/133 > >> > >> > Is ARCH_ARM32 or ARCH_ARMv7 too simple? > >> > Is it possible to have a 32-bit ARMv8? > >> Yes, ARMv8-R/M > > > > So what does mean CONFIG_RTE_ARCH_ARM? > > ARMv7? ARM32? > > Please consider a renaming. > > I'd rather not renaming becase it can be both ARMv7 and AARCH32, which > are ISA compatibility. > If further differentiation is needed, CONFIG_RTE_ARCH_ARMv7 is added > in the config, just like Jan Viktorin did. >> I don't understand. >> You say CONFIG_RTE_ARCH_ARM is for ARMv7 and AARCH32, right? >> Both are 32-bit right? >> Why not rename it to CONFIG_RTE_ARCH_ARM32? Hello, CONFIG_RTE_ARCH_ARMv7 entry specifies the certain architecture, subset of CONFIG_RTE_ARCH_ARM (which is 32b). For ARM64 we can differentiate among architectures v8, v9, ..., v64 :) as well. However, I doubt somebody will use dpdk on ARMv6. IMO, the major options should be CONFIG_RTE_ARCH_ARM and CONFIG_RTE_ARCH_ARM64. Jan Viktorin RehiveTech Sent from a mobile device
2015-12-08 18:21, Jianbo Liu: > On 8 December 2015 at 18:03, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > > 2015-12-08 15:56, Jianbo Liu: > >> On 8 December 2015 at 10:23, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > >> > 2015-12-08 09:50, Jianbo Liu: > >> >> On 8 December 2015 at 09:18, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > >> >> > 2015-12-03 23:02, Jianbo Liu: > >> >> >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) > >> >> >> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) > >> >> > [...] > >> >> >> +#ifdef RTE_ARCH_ARM > >> >> >> +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ > >> >> > > >> >> > I'm convinced there is a good reason why ARMv8 is also called ARCH_ARM64, > >> >> > and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why? > >> >> > > >> >> https://lkml.org/lkml/2012/7/15/133 > >> >> > >> >> > Is ARCH_ARM32 or ARCH_ARMv7 too simple? > >> >> > Is it possible to have a 32-bit ARMv8? > >> >> Yes, ARMv8-R/M > >> > > >> > So what does mean CONFIG_RTE_ARCH_ARM? > >> > ARMv7? ARM32? > >> > Please consider a renaming. > >> > >> I'd rather not renaming becase it can be both ARMv7 and AARCH32, which > >> are ISA compatibility. > >> If further differentiation is needed, CONFIG_RTE_ARCH_ARMv7 is added > >> in the config, just like Jan Viktorin did. > > > > I don't understand. > > You say CONFIG_RTE_ARCH_ARM is for ARMv7 and AARCH32, right? > > Both are 32-bit right? > > Why not rename it to CONFIG_RTE_ARCH_ARM32? > > I understand that you want to make the naming more clear. > But arm/arm64 are used in Linux kernel, I think it's better to stay the same. Linux supports ARM for a very long time. Doing a rename now is costly. The DPDK support is recent. Keeping a bad naming scheme because an old project follows this scheme is insane.
On Tue, 08 Dec 2015 11:38:46 +0100 Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > 2015-12-08 18:21, Jianbo Liu: > > On 8 December 2015 at 18:03, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > > > 2015-12-08 15:56, Jianbo Liu: > > >> On 8 December 2015 at 10:23, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > > >> > 2015-12-08 09:50, Jianbo Liu: > > >> >> On 8 December 2015 at 09:18, Thomas Monjalon <thomas.monjalon@6wind.com> wrote: > > >> >> > 2015-12-03 23:02, Jianbo Liu: > > >> >> >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) > > >> >> >> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) > > >> >> > [...] > > >> >> >> +#ifdef RTE_ARCH_ARM > > >> >> >> +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ > > >> >> > > > >> >> > I'm convinced there is a good reason why ARMv8 is also called ARCH_ARM64, > > >> >> > and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why? > > >> >> > > > >> >> https://lkml.org/lkml/2012/7/15/133 > > >> >> > > >> >> > Is ARCH_ARM32 or ARCH_ARMv7 too simple? > > >> >> > Is it possible to have a 32-bit ARMv8? > > >> >> Yes, ARMv8-R/M > > >> > > > >> > So what does mean CONFIG_RTE_ARCH_ARM? > > >> > ARMv7? ARM32? > > >> > Please consider a renaming. > > >> > > >> I'd rather not renaming becase it can be both ARMv7 and AARCH32, which > > >> are ISA compatibility. > > >> If further differentiation is needed, CONFIG_RTE_ARCH_ARMv7 is added > > >> in the config, just like Jan Viktorin did. > > > > > > I don't understand. > > > You say CONFIG_RTE_ARCH_ARM is for ARMv7 and AARCH32, right? > > > Both are 32-bit right? > > > Why not rename it to CONFIG_RTE_ARCH_ARM32? > > > > I understand that you want to make the naming more clear. > > But arm/arm64 are used in Linux kernel, I think it's better to stay the same. > > Linux supports ARM for a very long time. Doing a rename now is costly. > The DPDK support is recent. Keeping a bad naming scheme because an > old project follows this scheme is insane. I think, the idea about having CONFIG_RTE_ARCH_ARM32 is not bad. We should do it soon, however. Regards Jan
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc index 9924ff9..cbebd64 100644 --- a/config/defconfig_arm-armv7a-linuxapp-gcc +++ b/config/defconfig_arm-armv7a-linuxapp-gcc @@ -53,7 +53,6 @@ CONFIG_RTE_LIBRTE_KNI=n CONFIG_RTE_EAL_IGB_UIO=n # fails to compile on ARM -CONFIG_RTE_LIBRTE_ACL=n CONFIG_RTE_LIBRTE_LPM=n CONFIG_RTE_LIBRTE_TABLE=n CONFIG_RTE_LIBRTE_PIPELINE=n diff --git a/lib/librte_acl/Makefile b/lib/librte_acl/Makefile index 897237d..2e394c9 100644 --- a/lib/librte_acl/Makefile +++ b/lib/librte_acl/Makefile @@ -49,7 +49,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_bld.c SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_gen.c SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_scalar.c -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) SRCS-$(CONFIG_RTE_LIBRTE_ACL) += acl_run_neon.c CFLAGS_acl_run_neon.o += -flax-vector-conversions -Wno-maybe-uninitialized else diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c index e2fdebd..4ba9786 100644 --- a/lib/librte_acl/rte_acl.c +++ b/lib/librte_acl/rte_acl.c @@ -114,8 +114,11 @@ rte_acl_init(void) { enum rte_acl_classify_alg alg = RTE_ACL_CLASSIFY_DEFAULT; -#ifdef RTE_ARCH_ARM64 +#if defined(RTE_ARCH_ARM64) alg = RTE_ACL_CLASSIFY_NEON; +#elif defined(RTE_ARCH_ARM) + if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_NEON)) + alg = RTE_ACL_CLASSIFY_NEON; #else #ifdef CC_AVX2_SUPPORT if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2)) diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h b/lib/librte_eal/common/include/arch/arm/rte_vect.h index 21cdb4d..a33c054 100644 --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h @@ -53,6 +53,29 @@ typedef union rte_xmm { double pd[XMM_SIZE / sizeof(double)]; } __attribute__((aligned(16))) rte_xmm_t; +#ifdef RTE_ARCH_ARM +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ +static __inline uint8x16_t +vqtbl1q_u8(uint8x16_t a, uint8x16_t b) +{ + uint8_t i, pos; + rte_xmm_t rte_a, rte_b, rte_ret; + + vst1q_u8(rte_a.u8, a); + vst1q_u8(rte_b.u8, b); + + for (i = 0; i < 16; i++) { + pos = rte_b.u8[i]; + if (pos < 16) + rte_ret.u8[i] = rte_a.u8[pos]; + else + rte_ret.u8[i] = 0; + } + + return vld1q_u8(rte_ret.u8); +} +#endif + #ifdef __cplusplus } #endif