On Fri, 8 Jan 2021 at 11:47, Ilya Maximets <i.maxim...@ovn.org> wrote: > > DPDK forces '-mno-avx512f' flag for the application if the toolchain > used to build DPDK had broken AVX512 support. But OVS could be built > with a completely different or fixed toolchain with correct avx512 > support. In this case OVS will detect that toolchain is good and will > try to build AVX512-optimized classifier. However, '-mno-avx512f' > flag will be passed from the DPDK side breaking the build: > > In file included from /gcc/x86_64-linux-gnu/8/include/immintrin.h:55, > from /gcc/x86_64-linux-gnu/8/include/x86intrin.h:48, > from /dpdk/../x86_64-linux-gnu/dpdk/rte_vect.h:28, > from /dpdk/../x86_64-linux-gnu/dpdk/rte_memcpy.h:17, > from /dpdk/rte_mempool.h:51, > from /dpdk/rte_mbuf.h:38, > from ../lib/dp-packet.h:25, > from ../lib/dpif.h:380, > from ../lib/dpif-netdev.h:23, > from ../lib/dpif-netdev-lookup-avx512-gather.c:22: > /usr/lib/gcc/x86_64-linux-gnu/8/include/avx512bwintrin.h:413:1: error: > inlining failed in call to always_inline '_mm512_sad_epu8': > target specific option mismatch > _mm512_sad_epu8 (__m512i __A, __m512i __B) > > Fix that by stripping out `-mno-avx512f` as we already do for '-march'. > This will allow the OVS to decide if the AVX512 can be used. > > Reordering of CFLAGS (i.e. addign DPDK flags before OVS ones) is not an > option since autotools might reorder them back later and it's very > unpredictable. > > Reported-at: https://github.com/openvswitch/ovs-issues/issues/201 > Signed-off-by: Ilya Maximets <i.maxim...@ovn.org> > --- > acinclude.m4 | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/acinclude.m4 b/acinclude.m4 > index 60871f67a..b73526b60 100644 > --- a/acinclude.m4 > +++ b/acinclude.m4 > @@ -445,6 +445,12 @@ AC_DEFUN([OVS_CHECK_DPDK], [ > # forces in pkg-config since this could override user-specified options. > # It's enough to have -mssse3 to build with DPDK headers. > DPDK_INCLUDE=$(echo "$DPDK_INCLUDE" | sed 's/-march=[[^ ]]*//g') > + # Also stripping out '-mno-avx512f'. Support for AVX512 will be disabled > + # if OVS will detect that it's broken. OVS could be built with a > + # completely different toolchain that correctly supports AVX512, flags > + # forced by DPDK only breaks our feature detection mechanism and leads to > + # build failures: https://github.com/openvswitch/ovs-issues/issues/201 > + DPDK_INCLUDE=$(echo "$DPDK_INCLUDE" | sed 's/-mno-avx512f//g') > OVS_CFLAGS="$OVS_CFLAGS $DPDK_INCLUDE" > OVS_ENABLE_OPTION([-mssse3]) > > -- > 2.25.4
There are structs, defines and inlines in public headers that change depending on whether or not AVX* are used. I do not know if the resulting mix-and-match is safe to use, and most importantly if it is guaranteed to be supported, and I think it should be clarified first. Kind regards, Luca Boccassi _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
