From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v3 2/3] lpm: add support for NEON Date: Fri, 12 Feb 2016 09:42:43 +0100 Message-ID: <2092360.XjJLNmQxlY@xps13> References: <1449242086-19051-1-git-send-email-jerin.jacob@caviumnetworks.com> <8996069.HySAWEmhf4@xps13> <20160212064719.GA3772@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, viktorin@rehivetech.com To: Jerin Jacob Return-path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id B0D131396 for ; Fri, 12 Feb 2016 09:44:13 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id g62so52889190wme.0 for ; Fri, 12 Feb 2016 00:44:13 -0800 (PST) In-Reply-To: <20160212064719.GA3772@localhost.localdomain> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2016-02-12 12:17, Jerin Jacob: > On Thu, Feb 11, 2016 at 12:46:33PM +0100, Thomas Monjalon wrote: > > 2016-01-29 09:40, Jerin Jacob: > > > --- a/lib/librte_lpm/Makefile > > > +++ b/lib/librte_lpm/Makefile > > > +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) > > > +SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include += rte_lpm_neon.h > > > +else > > > SYMLINK-$(CONFIG_RTE_LIBRTE_LPM)-include += rte_lpm_sse.h > > > +endif > > [...] > > > --- a/lib/librte_lpm/rte_lpm.h > > > +++ b/lib/librte_lpm/rte_lpm.h > > > +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64) > > > +#include "rte_lpm_neon.h" > > > +#else > > > #include "rte_lpm_sse.h" > > > +#endif > > > > Instead of defaulting to x86 SSE, it would be better to replace > > "else" by "elif X86/SSE". > > I suggest using RTE_ARCH_X86 or RTE_CPUFLAG_SSEx. > > Some architectures(tile)[1] are planning to emulate SSE instruction used > in LPM for LPM library support.So that way it makes sense to use SSE as default. Not sure it is a great idea to emulate instructions of another arch. > But if anyone has any objections then I can add the check else let > keep in existing way. If Tile wants to use x86 code, it's better to do it explicitly (X86 || TILE). > [1] > http://dpdk.org/ml/archives/dev/2016-January/031147.html