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