From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so1.wedos.net (wes1-so1.wedos.net [46.28.106.15]) by dpdk.org (Postfix) with ESMTP id 62856A6A for ; Mon, 2 Nov 2015 16:39:14 +0100 (CET) Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz [147.229.13.147]) by wes1-so1.wedos.net (Postfix) with ESMTPSA id 3nqJM611glz4Nb; Mon, 2 Nov 2015 16:39:14 +0100 (CET) Date: Mon, 2 Nov 2015 16:36:27 +0100 From: Jan Viktorin To: "Hunt, David" Message-ID: <20151102163627.7a08bcc5@pcviktorin.fit.vutbr.cz> In-Reply-To: <5637809B.1000806@intel.com> References: <1446212959-19832-1-git-send-email-david.hunt@intel.com> <1446212959-19832-2-git-send-email-david.hunt@intel.com> <20151102045728.GB16413@localhost.localdomain> <56375597.8070805@intel.com> <20151102125743.GA9506@localhost.localdomain> <5637809B.1000806@intel.com> Organization: RehiveTech MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v3 1/6] eal/arm: add 64-bit armv8 version of rte_memcpy.h X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 15:39:14 -0000 On Mon, 2 Nov 2015 15:26:19 +0000 "Hunt, David" wrote: > On 02/11/2015 12:57, Jerin Jacob wrote: > > On Mon, Nov 02, 2015 at 12:22:47PM +0000, Hunt, David wrote: > >> Jerin, > >> I've just benchmarked the libc version against the hand-coded version of > >> the memcpy routines, and the libc wins in most cases. This code was just an > >> initial attempt at optimising the memccpy's, so I feel that with the current > >> benchmark results, it would better just to remove the assembly versions, and > >> use the libc version for the initial release on ARMv8. > >> Then, in the future, the ARMv8 experts are free to submit an optimised > >> version as a patch in the future. Does that sound reasonable to you? > > > > Make sense. Based on my understanding, other blocks are also not optimized > > for arm64. > > So better to revert back to CONFIG_RTE_FORCE_INTRINSICS and > > libc for initial version. > > > > BTW: I just tested ./arm64-armv8a-linuxapp-gcc/app/test and > > "byteorder_autotest" is broken. I think existing arm64 code is not optimized > > beyond CONFIG_RTE_FORCE_INTRINSICS. So better to use verified > > CONFIG_RTE_FORCE_INTRINSICS scheme. > > Agreed. > > > if you guys are OK with arm and arm64 as two different platform then > > I can summit the complete working patch for arm64.(as in my current source > > code "arm64" is a different platform(lib/librte_eal/common/include/arch/arm64/) > > Sure. That would be great. We initially started with two ARMv7 > patch-sets, and Jan merged into one. Something similar could happen for > the ARMv8 patch set. We just want to end up with the best implementation > possible. :) > It was looking like we can share a lot of common code for both architectures. I didn't know how much different are the cpuflags. IMHO, it'd be better to have two directories arm and arm64. I thought to refer from arm64 to arm where possible. But I don't know whether is this possible with the DPDK build system. Jan > Dave. > > > > -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic