Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

Björn Töpel
2024-04-02T14:25:27Z

Pu Lehui <pulehui@huaweicloud.com> writes:

> On 2024/3/29 6:07, Conor Dooley wrote:
>> On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote:
>>> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
>>>> From: Pu Lehui <pulehui@huawei.com>
>>>>
>>>> This patch relaxes the restrictions on the Zbb instructions. The hardware
>>>> is capable of recognizing the Zbb instructions independently, eliminating
>>>> the need for reliance on kernel compile configurations.
>>>
>>> This doesn't make sense to me.
>>
>> It doesn't make sense to me either. Of course the hardware's capability
>> to understand an instruction is independent of whether or not a
>> toolchain is capable of actually emitting the instruction.
>>
>>> RISCV_ISA_ZBB is defined as:
>>>
>>> Adds support to dynamically detect the presence of the ZBB
>>> extension (basic bit manipulation) and enable its usage.
>>>
>>> In other words, RISCV_ISA_ZBB=n should disable everything that attempts
>>> to detect Zbb at runtime. It is mostly relevant for code size reduction,
>>> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
>>> checks can be constant-folded.
>
> Thanks for review. My initial thought was the same as yours, but after
> discussions [0] and test verifications, the hardware can indeed
> recognize the zbb instruction even if the kernel has not enabled
> CONFIG_RISCV_ISA_ZBB. As Conor mentioned, we are just acting as a JIT to
> emit zbb instruction here. Maybe is_hw_zbb_capable() will be better?

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.

For these kind of optimizations, (IMO) it's better to let the BPF JIT
decide at run-time.

Björn