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 26E90A04DB; Fri, 16 Oct 2020 10:35:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9C46C1EB5E; Fri, 16 Oct 2020 10:35:20 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 025E01EB5D for ; Fri, 16 Oct 2020 10:35:18 +0200 (CEST) IronPort-SDR: PxKsdKVtbN3T0WMNKEQjIqWdjSKQzvVZjJ5HNDuUdVyJLmUwaCHEGrv4rRxB6coEysEPCXQgYy ebaI3ZxAIzKw== X-IronPort-AV: E=McAfee;i="6000,8403,9775"; a="166627128" X-IronPort-AV: E=Sophos;i="5.77,382,1596524400"; d="scan'208";a="166627128" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Oct 2020 01:35:16 -0700 IronPort-SDR: mmqCw7K4iR7b/5epX0N0DBa+oFKpLZHcOU3aQw25c+UOA8151N8G6ltFs/IdGpmpUu2sYpa0Mb liTQypa9+6KQ== X-IronPort-AV: E=Sophos;i="5.77,382,1596524400"; d="scan'208";a="531630767" 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:35:14 -0700 Date: Fri, 16 Oct 2020 09:35:10 +0100 From: Bruce Richardson To: Stephen Hemminger 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, jerinj@marvell.com Message-ID: <20201016083510.GB1008@bricha3-MOBL.ger.corp.intel.com> References: <20201015170804.GG554@bricha3-MOBL.ger.corp.intel.com> <2573869.E7my6rS1tG@thomas> <20201015144449.3c78230c@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201015144449.3c78230c@hermes.local> Subject: Re: [dpdk-dev] 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 02:44:49PM -0700, Stephen Hemminger wrote: > On Thu, 15 Oct 2020 19:14:48 +0200 > Thomas Monjalon wrote: > > > 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. > > > > I assume only some Rx/Tx functions are impacted. > > We probably need such disabling option per-file. > > > > > However, at this point, I think we need a little more investigation. Is > > > there any testing you can do to see if it's just in your driver, or in > > > perhaps a mempool driver/lib that the issue appears, or if it's just a > > > global slowdown? Do you see the impact with both clang and gcc? I'll > > > retest things a bit tomorrow on my end to see what I see. > > > > Yes we need to know which libs or files are impacted by -fPIC. > > The issue is that all shared libraries need to be built with PIC. > So it is a question of static vs shared library build. Well, partially yes, but really using fPIC should only have a very small difference in drivers. Therefore I'd like to know what's causing this massive drop because, while disabling fPIC in the static builds (perhaps per-component to avoid doubling the build time) will improve perf in the static case, it will still leave a perf drop when a user switches to shared libs. Since we want to move to a model where people are using shared libraries and can update seamlessly due to constant ABI, I therefore think we need to root cause this so we can fix the shared lib builds too - since disabling fPIC is not an option there. /Bruce