bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: Daniel Borkmann <daniel@iogearbox.net>, <bpf@vger.kernel.org>
Cc: Alexei Starovoitov <ast@fb.com>, <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next] selftests/bpf: change llvm flag -mcpu=probe to -mcpu=v3
Date: Wed, 19 Feb 2020 09:04:34 -0800	[thread overview]
Message-ID: <81fdc321-7bc2-d8aa-29dd-077e49e4fa6d@fb.com> (raw)
In-Reply-To: <956ccea3-0440-7c59-9c75-90cd7b25afb7@iogearbox.net>



On 2/19/20 8:56 AM, Daniel Borkmann wrote:
> On 2/19/20 1:42 AM, Yonghong Song wrote:
>> The latest llvm supports cpu version v3, which is cpu version v1
>> plus some additional 64bit jmp insns and 32bit jmp insn support.
>>
>> In selftests/bpf Makefile, the llvm flag -mcpu=probe did runtime
>> probe into the host system. Depending on compilation environments,
>> it is possible that runtime probe may fail, e.g., due to
>> memlock issue. This will cause generated code with cpu version v1.
> 
> But those are tiny BPF progs that LLVM is probing. If memlock is not
> sufficient, should it try to bump the limit with the diff needed and
> only if that fails as well then it bails out to v1.

The selftest is also trying to test the latest kernel, so we want
to keep cpu version as v3 always?

There are cases e.g., compilation on a devserver and selftests running 
in a VM. The linux directory is shared between the host and the qemu.
qemu runs latest kernel and devserver's old kernel may have small
memlock or in unlikely case the old kernel may simply not supporting the 
cpu v3, so in such cases, maybe forcing cpu=v3 is better since this is
what we intend to test?

> 
>> This may cause confusion as the same compiler and the same C code
>> generates different byte codes in different environment.
>>
>> Let us change the llvm flag -mcpu=probe to -mcpu=v3 so the
>> generated code will be the same regardless of the compilation
>> environment.
>>
>> Signed-off-by: Yonghong Song <yhs@fb.com>

  reply	other threads:[~2020-02-19 17:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-19  0:42 [PATCH bpf-next] selftests/bpf: change llvm flag -mcpu=probe to -mcpu=v3 Yonghong Song
2020-02-19  7:34 ` Andrii Nakryiko
2020-02-19 16:56 ` Daniel Borkmann
2020-02-19 17:04   ` Yonghong Song [this message]
2020-02-19 17:06   ` Alexei Starovoitov
2020-02-19 23:17     ` Alexei Starovoitov
2020-02-20  0:15       ` Daniel Borkmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81fdc321-7bc2-d8aa-29dd-077e49e4fa6d@fb.com \
    --to=yhs@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).