[dpdk-dev,v2,2/3] eal/acl: enable acl for armv7-a

Message ID 1449154976-16501-3-git-send-email-jianbo.liu@linaro.org (mailing list archive)
State Accepted, archived
Headers

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

Jerin Jacob Dec. 3, 2015, 3:13 p.m. UTC | #1
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
>
  
Thomas Monjalon Dec. 8, 2015, 1:18 a.m. UTC | #2
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?
  
Jianbo Liu Dec. 8, 2015, 1:50 a.m. UTC | #3
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
  
Thomas Monjalon Dec. 8, 2015, 2:23 a.m. UTC | #4
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.
  
Jianbo Liu Dec. 8, 2015, 7:56 a.m. UTC | #5
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.
  
Thomas Monjalon Dec. 8, 2015, 10:03 a.m. UTC | #6
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?
  
Jianbo Liu Dec. 8, 2015, 10:21 a.m. UTC | #7
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.
  
Jan Viktorin Dec. 8, 2015, 10:25 a.m. UTC | #8
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‎

‎
  
Thomas Monjalon Dec. 8, 2015, 10:38 a.m. UTC | #9
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.
  
Jan Viktorin Dec. 8, 2015, 11:27 a.m. UTC | #10
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
  

Patch

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