From: Stephen Hemminger <stephen@networkplumber.org>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Ali Alnubani <alialnu@nvidia.com>,
Bruce Richardson <bruce.richardson@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>, Asaf Penso <asafp@nvidia.com>,
david.marchand@redhat.com, arybchenko@solarflare.com,
ferruh.yigit@intel.com, honnappa.nagarahalli@arm.com,
jerinj@marvell.com
Subject: Re: [dpdk-dev] performance degradation with fpic
Date: Thu, 15 Oct 2020 14:44:49 -0700 [thread overview]
Message-ID: <20201015144449.3c78230c@hermes.local> (raw)
In-Reply-To: <2573869.E7my6rS1tG@thomas>
On Thu, 15 Oct 2020 19:14:48 +0200
Thomas Monjalon <thomas@monjalon.net> 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.
next prev parent reply other threads:[~2020-10-15 21:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 16:00 [dpdk-dev] performance degradation with fpic Ali Alnubani
2020-10-15 17:08 ` Bruce Richardson
2020-10-15 17:14 ` Thomas Monjalon
2020-10-15 17:28 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2020-10-16 8:29 ` Bruce Richardson
2020-10-16 8:39 ` Jerin Jacob
2020-10-15 21:44 ` Stephen Hemminger [this message]
2020-10-16 8:35 ` [dpdk-dev] " Bruce Richardson
2020-10-16 9:59 ` Bruce Richardson
2020-10-19 11:47 ` Ali Alnubani
2020-10-19 13:01 ` Bruce Richardson
2020-10-22 13:17 ` Ali Alnubani
2020-10-22 13:57 ` Bruce Richardson
2020-10-22 14:16 ` Ali Alnubani
2020-11-02 10:40 ` Ali Alnubani
2020-11-02 11:01 ` Luca Boccassi
2020-11-02 15:00 ` Bruce Richardson
2020-11-03 10:18 ` Thomas Monjalon
2020-11-03 10:45 ` Luca Boccassi
2020-11-03 11:23 ` Bruce Richardson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201015144449.3c78230c@hermes.local \
--to=stephen@networkplumber.org \
--cc=alialnu@nvidia.com \
--cc=arybchenko@solarflare.com \
--cc=asafp@nvidia.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.