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 87044A0521; Tue, 3 Nov 2020 11:45:25 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6AE2BC920; Tue, 3 Nov 2020 11:45:23 +0100 (CET) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id A56EEC918 for ; Tue, 3 Nov 2020 11:45:21 +0100 (CET) Received: by mail-wr1-f67.google.com with SMTP id b3so12064068wrx.11 for ; Tue, 03 Nov 2020 02:45:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=Qi9HZHRFh9h1Wvkr0WezXqFmwg6ZQKCa6CcR8SuM5Yo=; b=loY8GrqWHIULZZa8Ms0DcmKd+BIy+Aw01Y35nuMw4tKJz42kIZkIXarfhYRsoHXp7G HZzCSpYmkuGFN9gX711+MmaIZbQU4IGIczhJ98LF5XyIWKOXz/x4lnvoLxZnbvS7ooOF 0amlpYHSnajN8P3PSbOm6kF2Ta/V/Rm9g5qIw4b5lJw3fAFEMmqQCKJFDD3EUKTENhUs Z5uMmt7svOdSC9hpOp6zrGtVBzI2qz2UmzyxdP20XvD7lyVc97LmfgaEdGfYn++MTnzW A4nLwUEPqLYMLE7dspvgs60SqZ/j0CNFOIMoSQ5pIibAbYB/ge6pv5/bWBVc5vwKTXPc 0dlQ== X-Gm-Message-State: AOAM531tAcMjgsDs48xvbuJxMZwcZkT21I7srCtLXjF1WBES7n3QSen9 nc4nbw5/b3or5Qe0e/OPPPI= X-Google-Smtp-Source: ABdhPJwNzk9xQAlrgEed0iBtXWyFd7lNdQ0lKP7oDgFSHqWXIE0FewBGQg6/Sz3gvXvTlSFT3kt7LA== X-Received: by 2002:adf:e446:: with SMTP id t6mr24283082wrm.46.1604400320361; Tue, 03 Nov 2020 02:45:20 -0800 (PST) Received: from localhost ([2a01:4b00:f419:6f00:7a8e:ed70:5c52:ea3]) by smtp.gmail.com with ESMTPSA id f17sm27838994wrm.27.2020.11.03.02.45.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Nov 2020 02:45:19 -0800 (PST) Message-ID: From: Luca Boccassi To: Thomas Monjalon , Bruce Richardson 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 10:45:18 +0000 In-Reply-To: <7983217.MxgJTX9gS5@thomas> References: <20201102150053.GC1454@bricha3-MOBL.ger.corp.intel.com> <7983217.MxgJTX9gS5@thomas> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 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, 2020-11-03 at 11:18 +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, > > >=20 > > > 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 prev= ent creating shared libs in this case). > > > What do you suggest I do? Can we have per-pmd customized compilation = flags? > > >=20 > > > Regards, > > > Ali > > >=20 > > There are multiple possible ways to achieve this, but below are some id= eas: > >=20 > > 1. Take the changes for supporting function versioning and duplicate th= em > > 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 > >=20 > > 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 al= low > > the subdirectory build file, in this case mlx5/meson.ninja, to build an= y 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 si= ngle > > file, rather than marking the whole driver as needing rebuild. >=20 > Can it be done only in the driver? > No general meson change for this option? >=20 > > 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? >=20 > 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. The problem is with the specific case, not with general customizations. IIRC all libraries must have fpic to build a relocatable executable - you cannot mix and match. Missing this feature means no address layout randomization, which is really bad especially for a network application. --=20 Kind regards, Luca Boccassi