On Mon, Mar 17, 2025 at 10:50:24AM +0100, David Marchand wrote: > On Fri, Mar 14, 2025 at 6:44 PM Bruce Richardson > <bruce.richard...@intel.com> wrote: > > > > A number of drivers had special optimized AVX2 and AVX512 code paths > > for performance reasons, and these tended to have copy-pasted logic > > to build those files. Centralise that logic in the main > > drivers/meson.build file to avoid duplication. > > > > v2: add patch 4 to remove use of unnecessary CC_AVX2_SUPPORT flag > > > > Bruce Richardson (4): > > build: add generalized AVX handling for drivers > > net/intel: use common AVX build code > > drivers/net: build use common AVX handling > > drivers/net: remove AVX2 build-time define > > > > drivers/meson.build | 30 +++++++++++++++++++++++++++ > > drivers/net/bnxt/bnxt_ethdev.c | 2 -- > > drivers/net/bnxt/meson.build | 10 +-------- > > drivers/net/enic/meson.build | 10 +-------- > > drivers/net/intel/i40e/meson.build | 26 ++--------------------- > > drivers/net/intel/iavf/meson.build | 25 ++-------------------- > > drivers/net/intel/ice/meson.build | 25 ++-------------------- > > drivers/net/intel/idpf/meson.build | 25 ++-------------------- > > drivers/net/nfp/meson.build | 10 +-------- > > drivers/net/octeon_ep/meson.build | 13 +----------- > > drivers/net/octeon_ep/otx_ep_ethdev.c | 4 ---- > > drivers/net/virtio/meson.build | 9 +------- > > 12 files changed, 43 insertions(+), 146 deletions(-) > > event/dlb2 can be converted too, or is there something special about > this driver? >
Ideally, yes, but it's also a bit special in that it only builds *either* the SSE code path or the AVX-512 one, and has duplicate symbols/functions in the two files. This is a bit strange, and probably not what we want, so I may need to do some work on it before converting it to this scheme. > > As part of the discussion on the base drivers, and seeing this series, > it would be cool if we had a generic framework to specify a set of > cflags for a set of sources. I'd rather not have that. Meson doesn't support having per-c-file flags, and I don't think we should resort to massive amounts of hackery to try and support this. I think having the same set of cflags across a whole component is a good principle, one which we should only violate when we have to e.g. for base dirs, and for ISA-specific files. > But at least this series lgtm and is a first step. > Thanks. /Bruce
