From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 42F6AA04E7;
	Mon,  2 Nov 2020 16:01:08 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id C7887C900;
	Mon,  2 Nov 2020 16:01:06 +0100 (CET)
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 by dpdk.org (Postfix) with ESMTP id 52D9AC8FE
 for <dev@dpdk.org>; Mon,  2 Nov 2020 16:01:04 +0100 (CET)
IronPort-SDR: z2Kyntp/ULPGQpYA09NZorDWhKJ7WAgxCpib2zFOnfcz6tz4GTYP8CXRwk3vVOkBqL8yW+orQM
 FirL0uN4dvNA==
X-IronPort-AV: E=McAfee;i="6000,8403,9793"; a="230527010"
X-IronPort-AV: E=Sophos;i="5.77,445,1596524400"; d="scan'208";a="230527010"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga005.jf.intel.com ([10.7.209.41])
 by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
 02 Nov 2020 07:00:59 -0800
IronPort-SDR: VS3oqvQVBNSONvCkoOgFcEuaF9Jc0AwxXPoiGAfEwj3NQghHip68ROQKw8lzxaS0NW5LEcTDWj
 KHpEVhzEqkhQ==
X-IronPort-AV: E=Sophos;i="5.77,445,1596524400"; d="scan'208";a="538050254"
Received: from bricha3-mobl.ger.corp.intel.com ([10.252.49.238])
 by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA;
 02 Nov 2020 07:00:57 -0800
Date: Mon, 2 Nov 2020 15:00:53 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: Ali Alnubani <alialnu@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
 NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
 Asaf Penso <asafp@nvidia.com>
Message-ID: <20201102150053.GC1454@bricha3-MOBL.ger.corp.intel.com>
References: <DM6PR12MB4618640B2ABCFA4D3B33C445DA020@DM6PR12MB4618.namprd12.prod.outlook.com>
 <20201015170804.GG554@bricha3-MOBL.ger.corp.intel.com>
 <20201016095910.GD1008@bricha3-MOBL.ger.corp.intel.com>
 <DM6PR12MB4618C29C72D9D21C8DB846B0DA1E0@DM6PR12MB4618.namprd12.prod.outlook.com>
 <20201019130130.GA663@bricha3-MOBL.ger.corp.intel.com>
 <DM6PR12MB4618FB6373C01FEDE81D00C5DA1D0@DM6PR12MB4618.namprd12.prod.outlook.com>
 <20201022135738.GB90@bricha3-MOBL.ger.corp.intel.com>
 <DM6PR12MB4618128D8DB2C60A9EDEC972DA1D0@DM6PR12MB4618.namprd12.prod.outlook.com>
 <DM6PR12MB4618B5D9D93473E1488D11F8DA100@DM6PR12MB4618.namprd12.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DM6PR12MB4618B5D9D93473E1488D11F8DA100@DM6PR12MB4618.namprd12.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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.

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?

/Bruce