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 121FAA0521; Tue, 3 Nov 2020 12:23:34 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E089EC956; Tue, 3 Nov 2020 12:23:32 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id B9E4FC94A for ; Tue, 3 Nov 2020 12:23:29 +0100 (CET) IronPort-SDR: gTLCDfpcV8I73X0rb5ddxNki8W1ZCrQSMcF4UMEPg7TyfkRsbpjLe66ao1x8r84JLijUINNKyo GxxCQHGNfSlA== X-IronPort-AV: E=McAfee;i="6000,8403,9793"; a="168253537" X-IronPort-AV: E=Sophos;i="5.77,447,1596524400"; d="scan'208";a="168253537" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2020 03:23:28 -0800 IronPort-SDR: KXpYBZncAT7EhnIqGYk8Iw+hJcOHfTeco/fEoIjox8Epxto2fe6KY9+FFgGSy/7KDnfoHrxox9 dOWd3CIFhiJw== X-IronPort-AV: E=Sophos;i="5.77,447,1596524400"; d="scan'208";a="538454838" Received: from bricha3-mobl.ger.corp.intel.com ([10.249.45.202]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 03 Nov 2020 03:23:25 -0800 Date: Tue, 3 Nov 2020 11:23:21 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: bluca@debian.org, Ali Alnubani , dev@dpdk.org, Asaf Penso , ferruh.yigit@intel.com, jerinj@marvell.com, akhil.goyal@nxp.com, andrew.rybchenko@oktetlabs.ru, ajit.khaparde@broadcom.com, konstantin.ananyev@intel.com, viacheslavo@nvidia.com Message-ID: <20201103112321.GA1144@bricha3-MOBL.ger.corp.intel.com> References: <20201102150053.GC1454@bricha3-MOBL.ger.corp.intel.com> <7983217.MxgJTX9gS5@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7983217.MxgJTX9gS5@thomas> 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 Tue, Nov 03, 2020 at 11:18:57AM +0100, Thomas Monjalon wrote: > 02/11/2020 16:00, Bruce Richardson: > > On Mon, Nov 02, 2020 at 10:40:54AM +0000, Ali Alnubani wrote: > > > Hi Bruce, > > > > > > I was able to pin this down on drivers/net/mlx5/mlx5_rxtx.c. Removing -fPIC from its ninja recipe in build.ninja resolves the issue (had to prevent creating shared libs in this case). > > > What do you suggest I do? Can we have per-pmd customized compilation flags? > > > > > > Regards, > > > Ali > > > > > There are multiple possible ways to achieve this, but below are some ideas: > > > > 1. Take the changes for supporting function versioning and duplicate them > > from lib/meson.build to drivers/meson.build. Since function versioning > > support already requires everything to be built twice, we could set it to > > not use -fpic for the static libs in that case. Then mark mlx5 as using > > function versioning. This is a bit hackish though, so > > > > 2. The "objs" parameter from each sub-directory is not widely used, so we > > could split this easily enough into objs-shared and objs-static, and allow > > the subdirectory build file, in this case mlx5/meson.ninja, to build any c > > files manually to pass them back. This is more flexible, and also means > > that you can limit the files which are to be built twice to only the single > > file, rather than marking the whole driver as needing rebuild. > > Can it be done only in the driver? > No general meson change for this option? > Well, apart from splitting the objs variable into two, I don't see any other general meson changes being needed in this case. So yes, it makes any changes specific to the driver. That said, I have not tried to implement such a change, so the "in practice" may be different from the "in theory"! > > I'm sure there are other approaches too. However, I agree with Luca's > > comment that first approach should probably be to see if you can track down > > exactly why this one file is having problems. Could any of the slowdown be > > due to the fact that you use a common lib from your driver? Are there > > cross-driver calls in the fast-path that are suffering a penalty? > > Of course the performance will be analyzed in the long run. > However, such analyzis is more convenient if meson is flexible enough > to allow customization of the build. > And in general, I think it is good to have meson flexible > to allow any kind of driver build customization. > I'm partially agreeing and partially disagreeing here. While flexibility is something that people generally want, based off my experience with DPDK builds over the last few years, I think that there is an awful lot to be said for consistency! While we need to support special cases that we can't work around, there are many advantages to having everything built in the same way using common flags etc. I would really hate to see the flexibility translate into drivers all choosing to do their own special build customization. /Bruce