netdev - Re: [PATCH bpf-next 4/5] selftests/bpf: add benchmark for bpf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <97a9166f-7eec-49e2-1f94-ae2fc21dcf02@huawei.com>
Date:   Wed, 8 Dec 2021 21:47:34 +0800
From:   Hou Tao <houtao1@...wei.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
CC:     Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>, Yonghong Song <yhs@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 4/5] selftests/bpf: add benchmark for
 bpf_strncmp() helper

Hi,

On 12/7/2021 11:01 AM, Andrii Nakryiko wrote:
> On Tue, Nov 30, 2021 at 6:07 AM Hou Tao <houtao1@...wei.com> wrote:
>> Add benchmark to compare the performance between home-made strncmp()
>> in bpf program and bpf_strncmp() helper. In summary, the performance
>> win of bpf_strncmp() under x86-64 is greater than 18% when the compared
>> string length is greater than 64, and is 179% when the length is 4095.
>> Under arm64 the performance win is even bigger: 33% when the length
>> is greater than 64 and 600% when the length is 4095.
snip
>> +
>> +long hits = 0;
>> +char str[STRNCMP_STR_SZ];
>> +
>> +char _license[] SEC("license") = "GPL";
>> +
>> +static __always_inline int local_strncmp(const char *s1, unsigned int sz,
>> +                                        const char *s2)
>> +{
>> +       int ret = 0;
>> +       unsigned int i;
>> +
>> +       for (i = 0; i < sz; i++) {
>> +               /* E.g. 0xff > 0x31 */
>> +               ret = (unsigned char)s1[i] - (unsigned char)s2[i];
> I'm actually not sure if it will perform subtraction in unsigned form
> (and thus you'll never have a negative result) and then cast to int,
> or not. Why not cast to int instead of unsigned char to be sure?
It is used to handle the character which is greater than or equal with 0x80.
When casting these character into int, the result will be a negative value,
the compare result will always be negative and it is wrong because
0xff should be greater than 0x31.