Message ID | 1467288996-6109-1-git-send-email-jerin.jacob@caviumnetworks.com (mailing list archive) |
---|---|
State | Accepted, archived |
Delegated to: | Yuanhan Liu |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 42F0F2986; Thu, 30 Jun 2016 14:17:09 +0200 (CEST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0086.outbound.protection.outlook.com [157.56.110.86]) by dpdk.org (Postfix) with ESMTP id 06C432617 for <dev@dpdk.org>; Thu, 30 Jun 2016 14:17:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GNZue2koFY8efjD+oVRpVgIokN2ofaDEOFX1NvhHTig=; b=Et3RBOIrjFV/ihiDUs3JrmqbUkzMCe2PPuTWrKDngHe7BSc/LctXtO0bsXIC1YxVpxme6I6W0YOStCTScsSNZMF5/v+5x0IM7U7zxKIC1MKmFR4g6DidndFBg+QDsuX0+FJRL08x6YzDj14EwxyRGwlGRIYySBfsSo7okMQ1Jz4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain.localdomain (122.167.11.22) by BN3PR0701MB1717.namprd07.prod.outlook.com (10.163.39.16) with Microsoft SMTP Server (TLS) id 15.1.528.16; Thu, 30 Jun 2016 12:17:04 +0000 From: Jerin Jacob <jerin.jacob@caviumnetworks.com> To: <dev@dpdk.org> CC: <thomas.monjalon@6wind.com>, <olivier.matz@6wind.com>, Jerin Jacob <jerin.jacob@caviumnetworks.com> Date: Thu, 30 Jun 2016 17:46:36 +0530 Message-ID: <1467288996-6109-1-git-send-email-jerin.jacob@caviumnetworks.com> X-Mailer: git-send-email 2.5.5 In-Reply-To: <1464250025-9191-1-git-send-email-jerin.jacob@caviumnetworks.com> References: <1464250025-9191-1-git-send-email-jerin.jacob@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [122.167.11.22] X-ClientProxiedBy: MAXPR01CA0009.INDPRD01.PROD.OUTLOOK.COM (10.164.147.16) To BN3PR0701MB1717.namprd07.prod.outlook.com (10.163.39.16) X-MS-Office365-Filtering-Correlation-Id: ac30ab51-ff81-43a9-1a23-08d3a0e07362 X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1717; 2:n1ywS78LJPPfvzwCh6NKMqFGTjHqzaTj/K6h2cPQIUxCN36VLL9ghXsR1GhHiv0LIsE9Mds/NJ5zrE9kDWW7Z9gSx+Da90XlNNIMhLeUa/E/KlJ3hb7eVkTyymtV689U0uSi0LnhZ7sPDusgdaPERTFlLePIueePOUBVL4uMDbJH+slggwyDrn2ZiPABTCIx; 3:A8hQSJoo3OmvhirwoCwQRNhJDuWYjFPU0zFcHWr9mbf4Tzlj6p+y3j20ytA2ZyGZESHKZk4LSqISKQImQSMCWUFLuf4G+v8jTutP5WavQz9UAi2H07LgyMigYTD24sRd; 25:6N9Uv+b3K48Y9UrQUA1gsOTc7sv2Cni5SLELfyPkAjYxcZVAyzlOYnGz5F1sAWOutwc+E8hAohny2LC5Oy0V5s53hsX/dpB+B6Bv/GXPDugft53fbX9e9KmyGbrrTW/23Ovj9g7k7W+50A/5iItZskzjQibyZiTzEJMBg1MktMLE/slEOO+sqWXo6H0pP9D9iPRM+ITB2NKYbG3GfpoTBXFIYctSxHebjsvY+5W73dqKFNkOaPZkxLP9nSOAwRYeQMTlGqKFxs8Meq0f0adcoheN5cKPLu2N5jE2OWUeQwmtKGeWtHtrSBtPatanwCKxgrXzurBj5jkgARpmWs4IKRjWVFSsH5ZuqQLUsPdpqeAGCIyXmd/ZLOzQjSI+B+xQdKZ63khuEgSsY6peE7+ekhFmCRPzQmlwIGylYN8wytw= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0701MB1717; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1717; 31:KYkPfueGVUWONCPKcp/IZXP+00ABlZCOlLwiE/7riSImebNAdN1HtaB8mhioLP77A+9RlJchEu1E8DXX2A3OTDSWXjBB+oAegOHHujcRy+ud5iQ18q9kxs8LI9B2ALaJEBBKOKfczRa9jeRO2oyyiidxEewWrEoOFbZ6pJ0YCeOFXjN8ZC2fF6y35VUrq0zFaiSjXmucTKyDvd5AFZcC/Q==; 20:ntUo/uXkErkzn21nxQBdjgbdV/ZIc7l7GimaTLha1mcJ9uOmIFopneJ7b2FCfgtggUBbJHwePj8YnG8ELpym9/Fa/K5byu36Yl1bouo2pq9CscLDuj2CrNkovNM+ShdlYK+EMJ9DRlZa/Kz5EWxi9z/OCzbRkiS1bGLgG+5TmrcgYE9SIwGP2Ca6YX5KuDtEo8pTJ3N3LxIb0ABmY9Twu0ZzLLlAg/Icx5z3ROCmuMHSH41/bvBuwBoar7BwW3E7wUVXQ+oFfhZPgC8JXZedJ06KCWkjvJOKSI9C0nNDghvfdYjHw882eLiLYH9xzDN3fHzkj5x5YEV3jRNDHzSiE01zX+qwIE59UxFnzmflBXQmUGUKuqnZnZnczWlKAHc1Pt84U1DQ+JefExaytoy7itaZ1FzvCYalwb1YhFZ33IP/cDXtGH2O1sDwiAG2G4XbXWkjw/j9MRRb+EpW6PmJ5XPhojEOxATTZjusIx0pcXS/eepoVkoJvtzuyd8tI6AOFcHR6nVfRot4ZkHarXdimXM7XSq9ydf6HcaWp3lxG61gy3YVHNNaiiJssq2ITY91qFe72AojRy/+UQPRfBxZrzP5zkKVvXLcPaePv0kYZKA= X-Microsoft-Antispam-PRVS: <BN3PR0701MB1717A24CF5C9775F8C265B1381240@BN3PR0701MB1717.namprd07.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(131327999870524)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0701MB1717; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0701MB1717; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1717; 4:mjR2fG5MK8aYHL9erH2rTUjoZ8/tXBjvXXgWLzDU9p1/uLrZJquiKHFOs/ZcHCQ94W3meENzs/3MuGowmoml4ZgxYK+IxugKYRWKGKizilapSd/e62bdOwP8OCFdMGe2lcfhvxgqf/ggNxz3kmLYn85bHRbnci+aLSxFoYDz3OakXSA6o6mFpJjVjYXX57b3e9CfN6Z3KtQnB0aAo4Sgpw3MoRrS+hfkAnKsXJBVyZZmuvA8XncpNOc7Ls3Z5OX+jD6NQ53KvoMdbFlgH23QS5rYl4UjXrNO+obdOPll2UAi7KIZj2+zjsvZD4jvzcKQwojOG1V31NN/z+R+E8sU/YPF8C1t1MFeu1Po8HPopFe9uVS3MUm/9MSClhLkTWGrKB+RHXQx11an9YPzopd9PYlVQyfeKan7gABdh9JnU04EGMeBUuxazFVwPfxv84S+ X-Forefront-PRVS: 0989A7979C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(7916002)(189002)(199003)(81166006)(2950100001)(77096005)(97736004)(81156014)(92566002)(101416001)(4001430100002)(48376002)(8676002)(36756003)(586003)(47776003)(66066001)(305945005)(110136002)(33646002)(189998001)(19580395003)(50226002)(68736007)(107886002)(42186005)(7846002)(19580405001)(7736002)(2351001)(6116002)(2906002)(106356001)(229853001)(3846002)(105586002)(50466002)(4326007)(5003940100001)(76176999)(50986999)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0701MB1717; H:localhost.localdomain.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR0701MB1717; 23:MC0JEhwXc6o0qSxt/7uR7wgmYDYnflH/FbsCYbZ?= =?us-ascii?Q?HsQCluRJmhUUg5vbvGWkYEtfzW8aqt0C6IB+/NKlAf5IZE8AuFOevKQwUipd?= =?us-ascii?Q?FSesn9xPfJ76Bu5ubXTu0dcgMP8DJ4CPFqFNpx6u+jcQg3p6kewrxAhBCmtj?= =?us-ascii?Q?1lCVM8pA06ajsuFctttjrzueWjYyxs4t/xzsTRfNVaujZh2YU/WPMSr82s7T?= =?us-ascii?Q?oi8cvIXu64syAHI0g7DYItcBLwXu6jwbiETQIMqjIN3ztCRx9g4Qjv8Q9eCu?= =?us-ascii?Q?ng+vEDuAgzrnQU5BH49RwtdIIc+P9gCw0ZK6SmY9vdTMtDI8g1OEMYm5Z8MZ?= =?us-ascii?Q?um9VADlW+h3k2U+RbiNoXqB6HQdFKt76FlDB4ebV1CCYX7uOyfjbS2eUaRpQ?= =?us-ascii?Q?TtFYpyOFpJIdmmcw8vUc4COpsijQHZ4PN3kWhWTqUYacyzhN9Ffdw+Q8PV+H?= =?us-ascii?Q?acXQqF/t3Zo45EP/7SODnjBbXO45zXqlCm+d9CTVAVX27ab5SUgJxQ53QRfW?= =?us-ascii?Q?xRhSmeawnrlNqMtLVS+XU2pE26JGeHvFvPuOfpjY4y5CqBHMdUvuOGQaUd84?= =?us-ascii?Q?O2jt0LSHuXGo5TFNNPS7d9b65dgIsmUV/H5AGc6G+Uz05eTpElmcYBzvzz/q?= =?us-ascii?Q?xsp4aNuHxd0orVaJhcDT2dU+kdfRRCoHtQIImgSwsxpaIX8jL45iZTMX4Kx9?= =?us-ascii?Q?h4hS//SoAfNSAlYgK6eBU+KNhpdifAvDF5RUSvaKHjdcQP/XKlf8AD0NETI/?= =?us-ascii?Q?O1MPRsfytPMa+MyVwc/gVzp06eBG2L8IUWL7HzDPpFVpBmAA6sYaRa1Fmwh6?= =?us-ascii?Q?pEmcHFPqTv6LezJypeRuCfzOWdChDx4WgjBGBqKfZSKY4Z5oeTbideWa9MgB?= =?us-ascii?Q?v+c/HFGLCv226SlEU8FnHiOEv2x46Af4ilt9WCJ8m1nmxvAbDH2P7VgjnAnE?= =?us-ascii?Q?S32khtEjnJebRE/E3Twom+nqfbZE1HT0bChfcZ/nwhIal5hN689A7XwgJc7d?= =?us-ascii?Q?OoLGAEuvGK2goWjn6iPwrm1hfzdBvHettPHn+Zef6Lfj3jywUwNyxPcRjPz2?= =?us-ascii?Q?ZRgNrMUB6SoGwjdl83jQ3wyMCXiK2k9IeREpMAuE9of0kIxBasEQKd8QlTda?= =?us-ascii?Q?H7RzICGr2SXaWCDEUIu3XNL1YODLwhy6k?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0701MB1717; 6:TqkNx4DtX+XBomLtpEYLrInE3+ZXPFLy2lVPkmS/ibj93NHINIBqD1nOsMqZpzV5dbrMkvJVr6ksR0eN41dnsK7qtQHmyaUy7xVyP0xuIwDFusNtpVyMWZ2aDNKifaDCyglppQKe8Bfq8koKyU+Y9gO2uULvbHX0B9JAZy+WCXhGwY2LkOge4SRY7YlKOoEkZDDGE7oQoTdNOrWVJUQr5nw9hJSniX2PW6a8TKKBXt3IEZXp4lS5LgMRA6elqGELuK+QAJLXO+L6vHmOQKvDThY/y/AeSZV08wW4QCmRK4o=; 5:Qo7PFpyHOQ20zXO03ry1eC+/iwoOzAYAqdTZ4sS7D0/ECACpmec3q9P0+i2SW7+3XVTTN8sdAOFAz2/Z9AzXqfBdxnFlmissEurJfAnjiC9IRb7aznJNx/gZXqCYepA/eYHqqIPjJuYVaQTk83BGOA==; 24:73OKQxni8g71XhK1dshYVY6CKR2llCpi95QsKgZJ+/pIzdw8eF6RDBe0kOlVb5KMGNqYAzg9fonh8iYyfAfqKjM+UdcdNOxUG/Cdr07Nro0=; 7:Ek30P6zFjqM6pYEpLurZ2aKUQN5UerTRJHd8fljyGbpJlpbetyNq6OAayvyZmsuV74HRBpjHoigAIAWlzn9SCaMmDDUAOPAtm6zfq1l41Rwbkhkhh8ugx+plpWOrKVFvvPURs/O04vBMSK6EpaQ5o6Mttks/xeVP/9S0YR67RANaMnmsemLNcGTaDC2TqAR9VTv4b7IaxAtyGbR0PVh4aR8B1bY2gFAV5laONocTdSecNh+YUUFaUcwY5hy+4xBA SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2016 12:17:04.1315 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0701MB1717 Subject: [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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Jerin Jacob
June 30, 2016, 12:16 p.m. UTC
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> Acked-by: Olivier Matz <olivier.matz@6wind.com> --- v1..v2 Corrected the the git commit message(s/mbuf/mempool/g) v2..v3 re-base to master --- --- lib/librte_mempool/rte_mempool.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
Comments
2016-06-30 17:46, Jerin Jacob: > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> > Acked-by: Olivier Matz <olivier.matz@6wind.com> Applied, thanks
On 6/30/2016 6:28 PM, Thomas Monjalon wrote: > 2016-06-30 17:46, Jerin Jacob: >> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com> >> Acked-by: Olivier Matz <olivier.matz@6wind.com> > > Applied, thanks > Hi Jerin, This commit cause a compilation error on target i686-native-linuxapp-gcc with gcc6. Compilation error is: == Build drivers/net/virtio CC virtio_rxtx_simple.o In file included from /root/development/dpdk/build/include/rte_mempool.h:77:0, from /root/development/dpdk/drivers/net/virtio/virtio_rxtx_simple.c:46: /root/development/dpdk/drivers/net/virtio/virtio_rxtx_simple.c: In function ‘virtio_xmit_pkts_simple’: /root/development/dpdk/build/include/rte_memcpy.h:551:2: error: array subscript is above array bounds [-Werror=array-bounds] rte_mov16((uint8_t *)dst + 1 * 16, (const uint8_t *)src + 1 * 16); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/development/dpdk/build/include/rte_memcpy.h:552:2: error: array subscript is above array bounds [-Werror=array-bounds] rte_mov16((uint8_t *)dst + 2 * 16, (const uint8_t *)src + 2 * 16); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/development/dpdk/build/include/rte_memcpy.h:553:2: error: array subscript is above array bounds [-Werror=array-bounds] rte_mov16((uint8_t *)dst + 3 * 16, (const uint8_t *)src + 3 * 16); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /root/development/dpdk/build/include/rte_memcpy.h:554:2: error: array subscript is above array bounds [-Werror=array-bounds] rte_mov16((uint8_t *)dst + 4 * 16, (const uint8_t *)src + 4 * 16); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... ... Thanks, ferruh
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 <jerin.jacob@caviumnetworks.com> > >> Acked-by: Olivier Matz <olivier.matz@6wind.com> > > > > 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? --yliu
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 <jerin.jacob@caviumnetworks.com> > > >> Acked-by: Olivier Matz <olivier.matz@6wind.com> > > > > > > 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, I have tested on a x86 machine with gcc 6.1. I could n't see any issues with i686-native-linuxapp-gcc target 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) More over this issue seems like an issue from x86 rte_memcpy implementation. Jerin
On Tue, Jul 05, 2016 at 06:43:57PM +0530, 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 <jerin.jacob@caviumnetworks.com> > > > >> Acked-by: Olivier Matz <olivier.matz@6wind.com> > > > > > > > > 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 Thanks. Maybe it's good to include those info in the commit log next time. --yliu
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 <jerin.jacob@caviumnetworks.com> >>>>> Acked-by: Olivier Matz <olivier.matz@6wind.com> >>>> >>>> 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. Thanks, ferruh
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 <jerin.jacob@caviumnetworks.com> >>>>>> Acked-by: Olivier Matz <olivier.matz@6wind.com> >>>>> >>>>> 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
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 <jerin.jacob@caviumnetworks.com> >>>>>>> Acked-by: Olivier Matz <olivier.matz@6wind.com> >>>>>> >>>>>> 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
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h index b2a5197..c8a81e2 100644 --- a/lib/librte_mempool/rte_mempool.h +++ b/lib/librte_mempool/rte_mempool.h @@ -74,6 +74,7 @@ #include <rte_memory.h> #include <rte_branch_prediction.h> #include <rte_ring.h> +#include <rte_memcpy.h> #ifdef __cplusplus extern "C" { @@ -1028,7 +1029,6 @@ static inline void __attribute__((always_inline)) __mempool_generic_put(struct rte_mempool *mp, void * const *obj_table, unsigned n, struct rte_mempool_cache *cache, int flags) { - uint32_t index; void **cache_objs; /* increment stat now, adding in mempool always success */ @@ -1052,8 +1052,7 @@ __mempool_generic_put(struct rte_mempool *mp, void * const *obj_table, */ /* Add elements back into the cache */ - for (index = 0; index < n; ++index, obj_table++) - cache_objs[index] = *obj_table; + rte_memcpy(&cache_objs[0], obj_table, sizeof(void *) * n); cache->len += n;