[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQ+KVfcU6gvYPmLvPk3-SHwuWEbhttzE24gC0RSCQgxv6g@mail.gmail.com>
Date: Thu, 2 Dec 2021 18:09:01 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Hou Tao <houtao1@...wei.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>,
Network Development <netdev@...r.kernel.org>,
bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 0/5] introduce bpf_strncmp() helper
On Tue, Nov 30, 2021 at 6:07 AM Hou Tao <houtao1@...wei.com> wrote:
>
> Hi,
>
> The motivation for introducing bpf_strncmp() helper comes from
> two aspects:
>
> (1) clang doesn't always replace strncmp() automatically
> In tracing program, sometimes we need to using a home-made
> strncmp() to check whether or not the file name is expected.
>
> (2) the performance of home-made strncmp is not so good
> As shown in the benchmark in patch #4, the performance of
> bpf_strncmp() helper is 18% or 33% better than home-made strncmp()
> under x86-64 or arm64 when the compared string length is 64. When
> the string length grows to 4095, the performance win will be
> 179% or 600% under x86-64 or arm64.
I think 'home made' strncmp could have been written
differently. I bet in bpf assembly it would be much closer
in performance if not the same,
but the helper is useful.
The patch set doesn't apply cleanly.
Pls respin.
Powered by blists - more mailing lists