On Fri, Mar 18, 2016 at 11:04:49AM +0100, Thomas Monjalon wrote:
> 2016-03-18 10:52, Tomasz Kulasek:
> > +#if !defined(NO_HASH_MULTI_LOOKUP) && defined(__ARM_NEON)
>
> I think we should use CONFIG_RTE_ARCH_ARM_NEON here.
> Any ARM maintainer to confirm?
__ARM_NEON should work existing GCC, but it
szX
> > ; dev at dpdk.org; jianbo.liu at linaro.org
> > Subject: Re: [dpdk-dev] [PATCH v5] examples/l3fwd: em path performance fix
> >
> > Hello Thomas, Jerin, Tomasz, all...
> >
> > On Fri, 18 Mar 2016 12:00:24 +0100
> > Thomas Monjalon wrote:
> >
Hello Thomas, Jerin, Tomasz, all...
On Fri, 18 Mar 2016 12:00:24 +0100
Thomas Monjalon wrote:
> 2016-03-18 16:22, Jerin Jacob:
> > On Fri, Mar 18, 2016 at 11:04:49AM +0100, Thomas Monjalon wrote:
> > > 2016-03-18 10:52, Tomasz Kulasek:
> > > > +#if !defined(NO_HASH_MULTI_LOOKUP) && defined(_
> -Original Message-
> From: Jan Viktorin [mailto:viktorin at rehivetech.com]
> Sent: Friday, March 18, 2016 12:57
> To: Thomas Monjalon
> Cc: Jerin Jacob ; Kulasek, TomaszX
> ; dev at dpdk.org; jianbo.liu at linaro.org
> Subject: Re: [dpdk-dev] [PATCH v5] ex
2016-03-18 16:22, Jerin Jacob:
> On Fri, Mar 18, 2016 at 11:04:49AM +0100, Thomas Monjalon wrote:
> > 2016-03-18 10:52, Tomasz Kulasek:
> > > +#if !defined(NO_HASH_MULTI_LOOKUP) && defined(__ARM_NEON)
> >
> > I think we should use CONFIG_RTE_ARCH_ARM_NEON here.
> > Any ARM maintainer to confirm?
>
2016-03-18 10:52, Tomasz Kulasek:
> +#if !defined(NO_HASH_MULTI_LOOKUP) && defined(__ARM_NEON)
I think we should use CONFIG_RTE_ARCH_ARM_NEON here.
Any ARM maintainer to confirm?
Note that there is already another occurence of this compiler flag:
examples/l3fwd/l3fwd_em.c:#elif defined(__ARM_NEON
It seems that for the most use cases, previous hash_multi_lookup provides
better performance, and more, sequential lookup can cause significant
performance drop.
This patch sets previously optional hash_multi_lookup method as default.
It also provides some minor optimizations such as queue drain o
7 matches
Mail list logo