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.
