Message-ID: <d6eae62b-60fd-4f3c-92e4-7ea5f1c4fc68@huaweicloud.com>
Date: Wed, 3 Apr 2024 18:05:38 +0800
From: Pu Lehui <pulehui@...weicloud.com>
To: Conor Dooley <conor@...nel.org>, Björn Töpel
 <bjorn@...nel.org>
Cc: Stefan O'Rear <sorear@...tmail.com>, bpf@...r.kernel.org,
 linux-riscv@...ts.infradead.org, netdev@...r.kernel.org,
 Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
 <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>,
 Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
 John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
 Stanislav Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>, Mykola Lysenko <mykolal@...com>,
 Manu Bretelle <chantr4@...il.com>, Pu Lehui <pulehui@...wei.com>
Subject: Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb
 instructions


On 2024/4/3 9:20, Conor Dooley wrote:
> On Tue, Apr 02, 2024 at 09:00:45PM +0200, Björn Töpel wrote:
> 
>>>> I still think Lehui's patch is correct; Building a kernel that can boot
>>>> on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
>>>> the kernel proper, and iff Zbb is available at run-time the BPF JIT will
>>>> emit Zbb.
>>>
>>> This sentence is -ENOPARSE to me, did you accidentally omit some words?
>>> Additionally he config option has nothing to do with building kernels that
>>> boot on multiple platforms, it only controls whether optimisations for Zbb
>>> are built so that if Zbb is detected they can be used.
>>
>> Ugh, sorry about that! I'm probably confused myself.
> 
> Reading this back, I a bunch of words too, so no worries...
> 
>>>> For these kind of optimizations, (IMO) it's better to let the BPF JIT
>>>> decide at run-time.
>>>
>>> Why is bpf a different case to any other user in this regard?
>>> I think that the commit message is misleading and needs to be changed,
>>> because the point "the hardware is capable of recognising the Zbb
>>> instructions independently..." is completely unrelated to the purpose
>>> of the config option. Of course the hardware understanding the option
> 
> This should have been "understanding the instructions"...
> 
>>> has nothing to do with kernel configuration. The commit message needs to
>>> explain why bpf is a special case and is exempt from an
> 
> And this s/from an//...
> 
>>> I totally understand any point about bpf being different in terms of
>>> needing toolchain support, but IIRC it was I who pointed out up-thread.
> 
> And "pointed that out".
> 
> I always make a mess of these emails that I re-write several times :)
> 
>>> The part of the conversation that you're replying to here is about the
>>> semantics of the Kconfig option and the original patch never mentioned
>>> trying to avoid a dependency on toolchains at all, just kernel
>>> configurations. The toolchain requirements I don't think are even super
>>> hard to fulfill either - the last 3 versions of ld and lld all meet the
>>> criteria.
>>
>> Thanks for making it more clear, and I agree that the toolchain
>> requirements are not hard to fulfull.
>>
>> My view has been that "BPF is like userland", but I realize now that's
>> odd.
> 
> Yeah, I can understand that perspective, but it does seem rather odd to
> someone that isn't a bpf-ist.
> 
>> Let's make BPF similar to the rest of the RV kernel. If ZBB=n, then
>> the BPF JIT doesn't know about emitting Zbb.
> 

Hi Conor and Björn,

Thanks for your explanation. I totally agree with what you said, 
"CONFIG_RISCV_ISA_ZBB only controls whether optimizations for Zbb are 
built so that if Zbb is detected they can be used.".

Since the instructions emited by bpf jit are in kernel space, they 
should indeed be aligned in this regard.

PS: It's a bit difficult to understand this,😅 if I'm wrong please don't 
hesitate to tell me.

Powered by blists - more mailing lists