On 1/8/21 1:05 PM, Luca Boccassi wrote: > 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.
Sure. We definitely need to clarify that. If this is true, and DPDK cannot be used if the application is built with AVX512 support, but the DPDK itself was built without it, this means that OVS 2.14 with DPDK 19.11 is broken if users use the 'make' build system, since it is not possible to determine which options DPDK was built with in this case. And for pkg-config use case we will have to force disable AVX512 classifier in OVS if '-mno-avx512f' found inside $DPDK_INCLUDE. Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
