From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Viktorin Subject: Re: [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs Date: Wed, 2 Dec 2015 14:05:22 +0100 Message-ID: <20151202140522.4c9c342e@pcviktorin.fit.vutbr.cz> References: <1448995276-9599-1-git-send-email-jianbo.liu@linaro.org> <1448995276-9599-4-git-send-email-jianbo.liu@linaro.org> <20151201164139.GA12144@localhost.localdomain> <20151202080259.GA32494@localhost.localdomain> <20151202103903.GA4940@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Jerin Jacob Return-path: Received: from wes1-so1.wedos.net (wes1-so1.wedos.net [46.28.106.15]) by dpdk.org (Postfix) with ESMTP id 0BC8B2E81 for ; Wed, 2 Dec 2015 14:08:01 +0100 (CET) In-Reply-To: <20151202103903.GA4940@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" On Wed, 2 Dec 2015 16:09:06 +0530 Jerin Jacob wrote: > > > [snip] > > > IMO, it's not always good to emulate GCC defined intrinsics of > > > other architecture. What if a legacy DPDK application has such mappings > > > then BOOM, multiple definition, which one is correct? which one > > > to comment it out? Integration pain starts for DPDK library consumer:-( > > > > > They can include rte_vect.h in build/include directly, which is linked correctly > > to the one for that ARCH, so there is no need to worry about. > > I think you missed the point,I was trying to say that > legacy DPDK application and third party stacks uses SSE2NEON kind of > libraries > for quick integration, for example, something like this > https://github.com/jratcliff63367/sse2neon/blob/master/SSE2NEON.h > > AND they include "rte_lpm.h"(it internally includes rte_vect.h) > that lead to multiple definition and its not good. > > > > > > > >> > > > >> > IMO, it makes sense to not emulate the SSE intrinsics with NEON > > >> > Let's create the rte_vect_* as required. look at the existing patch. > > >> > > > >> I thought of creating a layer of SIMD over all the platforms before. > > >> But can't you see it make things complicated, considering there are > > >> only few simple intrinsic to implement? > > > > > > Not true, There were, a lot of SSE intrinsics needs be to emulated for ACL NEON > > > implementation if I were to take this approach and emulation comes with > > > the cost. > > > > > No, I will not re-implement all the intrinsic like that . > > I only do with the simple intrinsic, such as load/store, as you said below. > > but you forced to add _mm_and_si128 also to the list and emulated > _mm_and_si128 intrinsic. Am just saying no emulation. > Guys, do we want emulate x86 on ARM? I hope we don't ;). I think, as more platforms might come into DPDK, there will be a need for a proper abstract vector operations API. Yes, we have to describe this API to people. However, otherwise, the ARM guys must learn SSE and write for ARM platform something that looks quite odd. And if there are some "neon emulations" as shown above, it's definitely an argue to have the API that can hide those approachs. Regards Jan