From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D1090A04DB; Fri, 16 Oct 2020 10:30:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B5D0E1EB5E; Fri, 16 Oct 2020 10:30:05 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 8D3501EB5D for ; Fri, 16 Oct 2020 10:30:03 +0200 (CEST) IronPort-SDR: VRkMpYyxcTHt/jEA5hyV4+mIDIEag+31tL8/EZqGFlkVtlvHDcxRk4xYBr3bUO9tA5tRPKKy4b DNkyAXl+gY6g== X-IronPort-AV: E=McAfee;i="6000,8403,9775"; a="154362218" X-IronPort-AV: E=Sophos;i="5.77,382,1596524400"; d="scan'208";a="154362218" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2020 01:30:01 -0700 IronPort-SDR: rNhaUP6mu7Av0CbD1RP0D64sazeXxcK3xc+RDc2AuVgnxh55EoAmfn67xVEq3bqz4v2KF2rPq6 /HkR1EAIPo9g== X-IronPort-AV: E=Sophos;i="5.77,382,1596524400"; d="scan'208";a="531629109" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.54.208]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 16 Oct 2020 01:29:57 -0700 Date: Fri, 16 Oct 2020 09:29:51 +0100 From: Bruce Richardson To: Jerin Jacob Kollanukkaran Cc: Thomas Monjalon , Ali Alnubani , "dev@dpdk.org" , Asaf Penso , "david.marchand@redhat.com" , "arybchenko@solarflare.com" , "ferruh.yigit@intel.com" , "honnappa.nagarahalli@arm.com" Message-ID: <20201016082951.GA1008@bricha3-MOBL.ger.corp.intel.com> References: <20201015170804.GG554@bricha3-MOBL.ger.corp.intel.com> <2573869.E7my6rS1tG@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [dpdk-dev] [EXT] Re: performance degradation with fpic X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Oct 15, 2020 at 05:28:10PM +0000, Jerin Jacob Kollanukkaran wrote: > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Thursday, October 15, 2020 10:45 PM > > To: Ali Alnubani ; Bruce Richardson > > > > Cc: dev@dpdk.org; Asaf Penso ; > > david.marchand@redhat.com; arybchenko@solarflare.com; > > ferruh.yigit@intel.com; honnappa.nagarahalli@arm.com; Jerin Jacob > > Kollanukkaran > > Subject: [EXT] Re: performance degradation with fpic > > > > External Email > > > > ---------------------------------------------------------------------- > > 15/10/2020 19:08, Bruce Richardson: > > > On Thu, Oct 15, 2020 at 04:00:44PM +0000, Ali Alnubani wrote: > > > > We have been seeing in some cases that the DPDK forwarding > > performance > > > > is up to 9% lower when DPDK is built as static with meson compared to a > > > > build with makefiles. > > > > > > > > The same degradation can be reproduced with makefiles on older DPDK > > > > releases when building with EXTAR_CFLAGS set to “-fPIC”, it can also be > > > > resolved in meson when passing “pic: false” to meson’s static_library > > > > call (more tweaking needs to be done to prevent building shared > > > > libraries because this change breaks them). > > [...] > > > > Should we disable PIC in static builds? > > > > > > thanks for reporting, though it's strange that you see such a big impact. > > > In my previous tests with i40e driver I never noticed a difference > > > between make and meson builds, and I and some others here have been > > > using meson builds for any performance work for over a year now. That > > > being said let me reverify what I see on my end. > > > > > > In terms of solutions, disabling the -fPIC flag globally implies that > > > we can no longer build static and shared libs from the same sources, > > > so we would need to revert to doing either a static or a shared > > > library build but not both. If the issue is limited to only some > > > drivers or some cases, we can perhaps add in a build option to have > > > no-fpic-static builds, to be used in a cases where it is problematic. > > We have seen this issue earlier. Our issue was, meson, getting more performance > Than make build system(Based on different changeset). Initially we suspected fpic > is playing role. Based on our understanding, It not is fpic issue per say, it is more > of text section code alignment change was creating the issue. > Typically it happen with very "fine" grained, prefetches in Rx and Tx routines, then > All timing will get changed by radical change to text section by fpic. > Out of interest, what range of performance difference did you see, because the 9% reported is fairly massive, well beyond anything I would expect from such a change?