[dpdk-dev] performance degradation with fpic

[Luca Boccassi]

On Tue, 2020-11-03 at 11:18 +0100, Thomas Monjalon wrote:
> 02/11/2020 16:00, Bruce Richardson:
> > 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.
> 
> Can it be done only in the driver?
> No general meson change for this option?
> 
> > 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?
> 
> Of course the performance will be analyzed in the long run.
> However, such analyzis is more convenient if meson is flexible enough
> to allow customization of the build.
> And in general, I think it is good to have meson flexible
> to allow any kind of driver build customization.

The problem is with the specific case, not with general customizations.
IIRC all libraries must have fpic to build a relocatable executable -
you cannot mix and match. Missing this feature means no address layout
randomization, which is really bad especially for a network
application.

-- 
Kind regards,
Luca Boccassi