On Fri, Mar 14, 2025 at 5:24 PM Bruce Richardson <bruce.richard...@intel.com> wrote: > > On Fri, Mar 14, 2025 at 05:14:34PM +0100, David Marchand wrote: > > On Thu, Mar 13, 2025 at 6:31 PM Bruce Richardson > > <bruce.richard...@intel.com> wrote: > > > > > > On Tue, Mar 11, 2025 at 10:56:04AM +0100, David Marchand wrote: > > > > Annotate symbols with newly introduced export macros. > > > > > > > > For code not compiled by lib/meson.build or drivers/meson.build (like > > > > AVX > > > > separate libraries, or sources in /base/ drivers), the exported symbols > > > > are added in some file listed in the sources so they get caught by > > > > lib/meson.build or drivers/meson.build. > > > > > > > > Signed-off-by: David Marchand <david.march...@redhat.com> > > > > --- > > > > > > Just checking: for the AVX2 and similar instruction-set-specific > > > functions, > > > we don't get errors if those are not present in the actual link phase, > > > e.g. > > > when building on non-x86 platforms? We don't need to put an #ifdef around > > > the exports? > > > > We are not there yet, but it is likely MSVC linker will complain, indeed. > > > > #ifdef around the exports won't work, we would need a precompiler pass > > (and exclude rte_exports.h inclusion). > > > > Another option would be to provide stubs for those symbols when the > > additional AVX512 (for example) libraries are not compiled. > > > > But I think the simpler is to let a driver/library provide a set of > > sources to parse for exports... maybe via an extra variable? > > WDYT? > > > Yes, something like that could work. > > What I'd actually like more, but never have had time to actually try out is > to generalise the instruction-set-specific build stuff into the higher level > drivers/meson.build code. After all, much of the code for doing so is just > duplicated - check for AVX512 or AVX2 and if present build these files with > the extra flags for that instruction set. > > Something similar with the base code. Most base code builds follow pretty > much the exact same routine.
Having those separate libraries require special cases every time, so yes, it would be great if those could be factored in some shared mechanism in drivers/meson.build. Putting the AVX stuff aside, and back to why we need those separate libraries for base drivers... I think the main use is to waive some build warnings, is there something else? If so.. I think some drivers could already be cleaned (like net/e1000, net/ngbe, net/octeontx, net/thunderx, net/txgbe, raw/ifpga at a first glance). The AVX stuff seems a bit more complex, as there are multiple combinations... -- David Marchand
