From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 1F7C711A2 for ; Thu, 7 Jul 2016 15:51:32 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP; 07 Jul 2016 06:51:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,324,1464678000"; d="scan'208";a="135320713" Received: from fanssuch-mobl1.gar.corp.intel.com (HELO [10.255.140.198]) ([10.255.140.198]) by fmsmga004.fm.intel.com with ESMTP; 07 Jul 2016 06:51:27 -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> <577D3006.1080504@intel.com> Cc: Thomas Monjalon , dev@dpdk.org, olivier.matz@6wind.com, Pablo de Lara From: Ferruh Yigit Message-ID: <577E5E5C.2050000@intel.com> Date: Thu, 7 Jul 2016 14:51:24 +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: <577D3006.1080504@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: Thu, 07 Jul 2016 13:51:33 -0000 On 7/6/2016 5:21 PM, Ferruh Yigit wrote: > 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. I have sent a patch: http://dpdk.org/ml/archives/dev/2016-July/043492.html Giving a hint to compiler that variable "size" is related to the size of the source buffer fixes compiler warning. - This update is in virtio fast path, can you please review it from point of performance effect. - Isn't this surprisingly smart of compiler, or am I missing something J Thanks, ferruh