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 06463A0521; Tue, 3 Nov 2020 11:21:03 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 92121C914; Tue, 3 Nov 2020 11:19:05 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 8BA49C906 for ; Tue, 3 Nov 2020 11:19:02 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id DAFAB580A41; Tue, 3 Nov 2020 05:19:00 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 03 Nov 2020 05:19:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= PgB3IqHtRCo2lkVQ7kJ8c/xs5oDL5gfQxz7lchViOjU=; b=hQdPP6RFHowLtGTx kV1VNLEnK0DOTukZv7ARjfMMjkKGzhtYRsg8OJaa7Uu2j+XqDNku5/H8ORETT27I VIAfuD2PPw1C1ME+JSaICI+tPrH8GxCMkBuXNHvSMUlhmRQ9J8L3h/hMYWUHw0hc jpXQOgXH3m1Ynjz8ASWDDFDBs/XIM7nf3dsBrMVF1Iau9/eY9D0XIaC4zXC3eku7 u6QEUcT/owtKVqj2p+b8mDVAB7N8hy9SVAfZ0OiGF+Mq6m9L2qGuGTv8ejr/L83t jvBeTmNRKqLDz5Spu3cjqQGg+ifCzgpH1OHl5HAamndkrALt7nMfZDBXyDbP6mmd 2ev5tg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=PgB3IqHtRCo2lkVQ7kJ8c/xs5oDL5gfQxz7lchViO jU=; b=DZqs0REtrcGdq7biGeaTxMWQpMyrVmg3keAHaieEMkioOPOUR+FYJMW9T nlTx24bNAWm2EMOka0t9wbXwqvXx+XewuRfs3jSqWVydvoCgg0wcGu3nc3n8qRfL tH9RTzkcxenGFRkHKeHy7i/a3/Fo3ytAhA5S9Wz2YfbCDhJOpro3gIQvgIvCcNFC dWNbW6B0T4DUegwhgRYpVwxC9WARhxrDDk5LAVfW5nAzr+afDqm/WIVdp6Pjqwfo h7NMRi7mAIScdzaYTfmLfevuQrvmkGiulC8b8mR+Z/yKeHsnqV4yNfrKOauCEDQQ AMMCtlS9QQekmq2INWMR+75WLCiCw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtfedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id EF6DF3280059; Tue, 3 Nov 2020 05:18:58 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson , bluca@debian.org Cc: 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 Date: Tue, 03 Nov 2020 11:18:57 +0100 Message-ID: <7983217.MxgJTX9gS5@thomas> In-Reply-To: <20201102150053.GC1454@bricha3-MOBL.ger.corp.intel.com> References: <20201102150053.GC1454@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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? > 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.