From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16]) by dpdk.org (Postfix) with ESMTP id C46822C47 for ; Sun, 20 Mar 2016 10:46:50 +0100 (CET) Received: from jvn (47.215.broadband18.iol.cz [109.81.215.47]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3qSYyL357Wzqv; Sun, 20 Mar 2016 10:46:50 +0100 (CET) Date: Sun, 20 Mar 2016 10:46:55 +0100 From: Jan Viktorin To: Thomas Monjalon Cc: dev@dpdk.org, jerin.jacob@caviumnetworks.com, tomaszx.kulasek@intel.com, jianbo.liu@linaro.org Message-ID: <20160320104655.45a5c863@jvn> In-Reply-To: <20160320104110.3c05f405@jvn> References: <1458417485-29436-1-git-send-email-viktorin@rehivetech.com> <1458417485-29436-5-git-send-email-viktorin@rehivetech.com> <1752293.0PmA76bAcf@xps13> <20160320104110.3c05f405@jvn> Organization: RehiveTech X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 4/4] eal/arm: introduce CONFIG_RTE_ARCH_ARM_NEON_MEMCPY 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: Sun, 20 Mar 2016 09:46:50 -0000 On Sun, 20 Mar 2016 10:41:10 +0100 Jan Viktorin wrote: > On Sat, 19 Mar 2016 21:14:57 +0100 > Thomas Monjalon wrote: > > > 2016-03-19 20:58, Jan Viktorin: > > > The flag is used to enable memcpy optimizations in EAL. As it is not always > > > the performance benefit, the flag allows to disable it. > > > > Ideally the default should be to choose the best optimization. > > If it is not possible, it would help to have some comments explaining > > how to choose wether enabling NEON memcpy or not. The related statistics are mentioned here: commit 04a2fde35daf5e9a271e72331a70b48b951d7568 Author: Vlastimil Kosar Date: Tue Nov 3 00:47:20 2015 +0100 eal/arm: add vector memcpy for ARMv7 It's quite difficult to easily summarize it, especially for so many CPUs... > > Ok, we can rename the option to CONFIG_RTE_ARCH_ARM_AVOID_NEON_MEMCPY, > delete it from the defconfig and change the test in rte_memcpy_32.h to > > #ifndef CONFIG_RTE_ARCH_ARM_AVOID_NEON_MEMCPY > > Alternatively, to have a positive test like > > #ifdef CONFIG_RTE_ARCH_ARM_AVOID_NEON_MEMCPY > > I can create a bigger change that moves the non-neon-memcpy up in the > file... > > Should I resend the whole series as v3? > > Regards > Jan -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic