[dpdk-dev] performance degradation with fpic

Bruce Richardson bruce.richardson at intel.com
Fri Oct 16 10:35:10 CEST 2020


On Thu, Oct 15, 2020 at 02:44:49PM -0700, Stephen Hemminger wrote:
> On Thu, 15 Oct 2020 19:14:48 +0200
> Thomas Monjalon <thomas at 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.

Well, partially yes, but really using fPIC should only have a very small
difference in drivers. Therefore I'd like to know what's causing this
massive drop because, while disabling fPIC in the static builds (perhaps
per-component to avoid doubling the build time) will improve perf in the
static case, it will still leave a perf drop when a user switches to shared
libs. Since we want to move to a model where people are using shared
libraries and can update seamlessly due to constant ABI, I therefore think
we need to root cause this so we can fix the shared lib builds too - since
disabling fPIC is not an option there.

/Bruce


More information about the dev mailing list