On Mon, Sep 30, 2024 at 5:57 PM Bruce Richardson
<bruce.richard...@intel.com> wrote:
>
> On Mon, Sep 30, 2024 at 05:38:44PM +0200, David Marchand wrote:
> > On Fri, Sep 6, 2024 at 4:11 PM Bruce Richardson
> > <bruce.richard...@intel.com> wrote:
> > >
> > > The AVX-512 copy code in multiple drivers was incorrect for 32-bit as it
> > > assumed that each pointer was always 8B in size.
> > >
> > > Bruce Richardson (4):
> > > net/i40e: fix AVX-512 pointer copy on 32-bit
> > > net/ice: fix AVX-512 pointer copy on 32-bit
> > > net/iavf: fix AVX-512 pointer copy on 32-bit
> > > common/idpf: fix AVX-512 pointer copy on 32-bit
> > >
> > > drivers/common/idpf/idpf_common_rxtx_avx512.c | 7 +++++++
> > > drivers/net/i40e/i40e_rxtx_vec_avx512.c | 7 +++++++
> > > drivers/net/iavf/iavf_rxtx_vec_avx512.c | 7 +++++++
> > > drivers/net/ice/ice_rxtx_vec_avx512.c | 7 +++++++
> > > 4 files changed, 28 insertions(+)
> >
> > Sorry, not directly related to this series, but as I was checking some
> > AVX512 patch, I suspect some drivers are missing runtime checks for
> > availability of some AVX512 instructions:
> >
> > $ for meson in $(git grep -l __AVX512[^_]*__
> > 'drivers/**/meson.build'); do dir=$(dirname $meson); for flag in $(git
> > grep -ho __AVX512[^_]*__ $dir | sort -u); do flag=${flag%%__};
> > flag=${flag##__}; git grep -ql
> > rte_cpu_get_flag_enabled.RTE_CPUFLAG_$flag $dir || echo
> > RTE_CPUFLAG_$flag check missing in $dir; done; done
> >
> > RTE_CPUFLAG_AVX512BW check missing in drivers/common/idpf
> > RTE_CPUFLAG_AVX512DQ check missing in drivers/common/idpf
> > RTE_CPUFLAG_AVX512F check missing in drivers/common/idpf
> > RTE_CPUFLAG_AVX512VL check missing in drivers/net/i40e
> > RTE_CPUFLAG_AVX512VL check missing in drivers/net/ice
> >
> > Maybe some flags are implictly available... worth a confirmation from
> > Intel in any case from my pov.
> >
>
> I think it would be good practice to explicitly check for all the AVX-512
> extensions actually used. Ideally, as a cleanup, we should probably check
> for those listed (f, bw, dq and vl) once early in the config and reuse that
> value throughout the build, rather than having each and every PMD
> continually check them.
This simplification on the build side looks good.
On the other hand, vectorized handlers in libraries and drivers are
selected based on some AVX512 instructions availability at runtime.
Don't we need to validate *runtime* availability of each of those
instructions in each library/driver?
--
David Marchand
