[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d6bd59f0-ba79-4e76-9fb7-aa07f86e4043@google.com>
Date: Thu, 4 Jan 2024 16:32:39 -0500
From: Barret Rhoden <brho@...gle.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Andrii Nakryiko <andrii@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>, mattbobrowski@...gle.com,
bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next 2/2] selftests/bpf: add inline assembly helpers
to access array elements
On 1/3/24 16:21, Andrii Nakryiko wrote:
> On Wed, Jan 3, 2024 at 12:06 PM Barret Rhoden<brho@...gle.com> wrote:
>> On 1/3/24 14:51, Andrii Nakryiko wrote:
>>> I'm curious how bpf_cmp_likely/bpf_cmp_unlikely (just applied to
>>> bpf-next) compares to this?
>> these work great!
>>
>> e.g.
>>
>> if (bpf_cmp_likely(idx, <, NR_MAP_ELEMS))
>> map_elems[idx] = i;
>>
>> works fine. since that's essentially the code that bpf_array_elem() was
>> trying to replace, i'd rather just use the new bpf_cmp helpers than have
>> the special array_elem helpers.
> ok, cool, thanks for checking! The less special macros, the better.
sorry - turns out it only worked in testing. in my actual program, i
still run into issues. the comparison is done, which is what bpf_cmp
enforces. but the compiler is discarding the comparison. i have more
info in the other thread, but figured i'd mention it here too. =(
Powered by blists - more mailing lists