[dpdk-dev] performance degradation with fpic

Stephen Hemminger stephen at networkplumber.org
Thu Oct 15 23:44:49 CEST 2020


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.


More information about the dev mailing list