[ovs-dev] ddlog OVN with OVS AVX512

Ben Pfaff blp at ovn.org
Fri Nov 6 17:16:31 UTC 2020


On Fri, Nov 06, 2020 at 05:00:57PM +0100, Ilya Maximets wrote:
> On 11/6/20 4:25 AM, Ben Pfaff wrote:
> > Numan, during the OVN meeting today, you reported that building current
> > master of OVS, on a machine that supports AVX512, and then building OVN
> > based on that, caused the following build failure:

[...]

> > However, I tried this myself just now (on a laptop that does indeed have
> > AVX512), and I can't see the failure.  Do you have any suggestions on
> > what else I might need to cause it?
> 
> Hi Ben,
> 
> You need also check your version of binutils.  Assembler from some versions
> of binutils (2.30 and 2.31) generates incorrect avx512 instructions, so OVS
> disables build of avx512 code on these systems.  See OVS_CHECK_BINUTILS_AVX512
> function in m4/openvswitch.m4.  Some distributions might have fix backported,
> so OVS checks the actual behavior by compiling a reproducer.
> 
> To manually check if your binutils broken:
> 
> 1. echo 'vpgatherqq 0x8(,%ymm1,1),%ymm0{%k2}' | as --64 -
> 2. objdump -d  --no-show-raw-insn a.out | grep vpgatherqq
> 
> Bad results:
>    0:   vpgatherqq 0x1(,%ymm1,1),%ymm0{%k2}
> 
> Correct results:
>    0:   vpgatherqq 0x8(,%ymm1,1),%ymm0{%k2}

Hmm, I do get the right results on my system here (Fedora 32).  And I
see that configure thinks the same thing (from config.log):

    configure:17710: checking whether gcc accepts -mavx512f
    configure:17721: gcc -c -g -O2 -fno-diagnostics-show-caret -fno-common -fno-omit-frame-pointer -Werror -mavx512f  conftest.c >&5
    configure:17721: $? = 0
    configure:17734: result: yes
    configure:17751: checking whether gcc accepts -mavx512f
    configure:17775: result: yes
    configure:17808: checking target hint for cgcc
    configure:17822: result: x86_64
    configure:17833: checking vector options for cgcc
    configure:17837: result: -D__MMX__=1 -D__MMX_WITH_SSE__=1 -D__SSE2_MATH__=1 -D__SSE_MATH__=1 -D__SSE__=1 -D__SSE2__=1 
    configure:17876: checking whether DPCLS Autovalidator is default implementation
    configure:17879: result: no
    configure:17887: checking binutils avx512 assembler checks passing
    configure:17908: result: yes

I'll do a full clean-and-rebuild and see if there's something funny
going on.

I wonder whether it depends on the Rust toolchain version?  I'll update
that too:

   stable-x86_64-unknown-linux-gnu updated - rustc 1.47.0 (18bf6b4f0 2020-10-07) (from rustc 1.45.2 (d3fb005a3 2020-07-31))
  nightly-x86_64-unknown-linux-gnu updated - rustc 1.49.0-nightly (ffa2e7ae8 2020-10-24) (from rustc 1.47.0-nightly (6c8927b0c 2020-07-26))


More information about the dev mailing list