From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id DF9AC7F00 for ; Wed, 6 Jul 2016 18:21:48 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 06 Jul 2016 09:21:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,319,1464678000"; d="scan'208";a="1016716719" Received: from syueh-mobl12.gar.corp.intel.com (HELO [10.255.149.163]) ([10.255.149.163]) by fmsmga002.fm.intel.com with ESMTP; 06 Jul 2016 09:21:29 -0700 To: Jerin Jacob , Yuanhan Liu References: <1464250025-9191-1-git-send-email-jerin.jacob@caviumnetworks.com> <1467288996-6109-1-git-send-email-jerin.jacob@caviumnetworks.com> <1752001.JOCExCpW7T@xps13> <577B7317.50608@intel.com> <20160705113246.GI26521@yliu-dev.sh.intel.com> <20160705131356.GA12235@localhost.localdomain> <577BBF9F.7070503@intel.com> Cc: Thomas Monjalon , dev@dpdk.org, olivier.matz@6wind.com, Pablo de Lara From: Ferruh Yigit Message-ID: <577D3006.1080504@intel.com> Date: Wed, 6 Jul 2016 17:21:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <577BBF9F.7070503@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v3] mempool: replace c memcpy code semantics with optimized rte_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: Wed, 06 Jul 2016 16:21:49 -0000 On 7/5/2016 3:09 PM, Ferruh Yigit wrote: > On 7/5/2016 2:13 PM, Jerin Jacob wrote: >> On Tue, Jul 05, 2016 at 07:32:46PM +0800, Yuanhan Liu wrote: >>> On Tue, Jul 05, 2016 at 09:43:03AM +0100, Ferruh Yigit wrote: >>>> On 6/30/2016 6:28 PM, Thomas Monjalon wrote: >>>>> 2016-06-30 17:46, Jerin Jacob: >>>>>> Signed-off-by: Jerin Jacob >>>>>> Acked-by: Olivier Matz >>>>> >>>>> Applied, thanks >>>>> >>>> >>>> Hi Jerin, >>>> >>>> This commit cause a compilation error on target i686-native-linuxapp-gcc >>>> with gcc6. >>> >>> Besides that, I'm more curious to know have you actually seen any >>> performance boost? >> >> let me first address your curiosity, >> http://dpdk.org/dev/patchwork/patch/12993/( check the second comment) >> http://dpdk.org/ml/archives/dev/2016-June/042701.html >> >> Ferruh, > > Hi Jerin, > >> >> I have tested on a x86 machine with gcc 6.1. I could n't see any issues >> with i686-native-linuxapp-gcc target > Thanks for investigating the issue. > >> >> Steps following to create gcc 6.1 toolchain >> https://sahas.ra.naman.ms/2016/05/31/building-gcc6-1-on-fedora-23/ >> (removed --disable-multilib to have support for -m32) >> >> ➜ [dpdk-master] $ gcc -v >> Using built-in specs. >> COLLECT_GCC=gcc >> COLLECT_LTO_WRAPPER=/opt/gcc-6.1.0/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper >> Target: x86_64-pc-linux-gnu >> Configured with: ../gcc-6.1.0/configure --prefix=/opt/gcc-6.1.0 >> --enable-languages=c,c++ --enable-libmudflap --with-system-zlib >> Thread model: posix >> gcc version 6.1.0 (GCC) > I am using Fedora24, which has gcc6 (6.1.1) as default. > >> >> More over this issue seems like an issue from x86 rte_memcpy implementation. > You are right. But i686 compilation starts failing with this commit. > And reverting this commit in the current HEAD solves the compilation > problem. > I am not really clear about reason of the compilation error. The compile error is because compiler is so smart now and at the same time not enough smart. Call stack is as following: virtio_xmit_pkts_simple virtio_xmit_cleanup rte_mempool_put_bulk rte_mempool_generic_put __mempool_generic_put rte_memcpy The array used as source buffer in virtio_xmit_cleanup (free) is a pointer array with 32 elements, in 32bit this makes 128 bytes. in rte_memcpy() implementation, there a code piece as following: if (size > 256) { rte_move128(...); rte_move128(...); <--- [1] .... } The compiler traces the array all through the call stack and knows the size of array is 128 and generates a warning on above [1] which tries to access beyond byte 128. But unfortunately it ignores the "(size > 256)" check. In 64bit, this warning is not generated because array size becomes 256 bytes. So this warning is a false positive. Although I am working on it, if anybody has a suggestion to prevent warning, quite welcome. At worst I will disable this compiler warning for the file. Thanks, ferruh