From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Matt Fleming <matt@readmodwrite.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Shuah Khan <shuah@kernel.org>,
kernel-team <kernel-team@cloudflare.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Martin KaFai Lau <martin.lau@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Network Development <netdev@vger.kernel.org>,
Matt Fleming <mfleming@cloudflare.com>
Subject: Re: [PATCH bpf-next v3] selftests/bpf: Add LPM trie microbenchmarks
Date: Fri, 8 Aug 2025 09:42:55 -0700 [thread overview]
Message-ID: <CAADnVQ+Q6qqz_kCibF6MGCOWAH4WH6XypYSCZjQzW7SP2yyodA@mail.gmail.com> (raw)
In-Reply-To: <CAENh_SRxK56Xr1=4MX4GhZuc0GF4z5+Q8VueTK0LDLj3wg_zXg@mail.gmail.com>
On Fri, Aug 8, 2025 at 7:21 AM Matt Fleming <matt@readmodwrite.com> wrote:
>
> On Thu, Jul 31, 2025 at 5:41 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > well, random-key update when the map is full is also quite different from
> > random-key update when the map is empty.
> >
> > Instead doing an update from user space do timed ops:
> > 1 start with empty map, update (aka insert) all keys sequentially
> > 2 lookup all sequentially
> > 3 delete all sequentially
> > 4 update (aka insert) all sequentially
> > 5 lookup random
> > 6 update random
> > 7 delete all random
> >
> > The elapsed time for 1 and 4 should be exactly the same.
> > While all others might have differences,
> > but all can be compared to each other and reasoned about.
>
> Having both sequential and random access for the benchmarks is fine,
> but as far as I can tell the scheme you propose is not how the bpf
> bench framework is implemented.
>
> Plus, handing off a map between subtests is brittle and prone to
> error. What if I just want to investigate the sequential access update
> time? The cost of the most expensive op (probably delete) is going to
> dwarf all over timings making it difficult to separate them and this
> scheme is going to be susceptible to noise if I can't crank up the
> number of iterations without altering the number of entries in the
> map. Microbenchmarks mitigate noise/run-to-run variance by doing a
> single op over and over again.
The bench has to repeat the operation obviously.
The point is that it cannot benchmark 'delete' in isolation.
And it cannot benchmark 'update of empty aka insert' in isolation.
So some operations have to be paired and when another one
can be done standalone then the delta is the performance for the other.
In the above 2,5,6 are repeatable. The others need to be paired.
7 with pure random is probably not a good idea, since it will
try to delete some keys that were already deleted and will skew the numbers.
next prev parent reply other threads:[~2025-08-08 16:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-22 15:01 [PATCH bpf-next v3] selftests/bpf: Add LPM trie microbenchmarks Matt Fleming
2025-07-28 14:34 ` Alexei Starovoitov
2025-07-29 13:56 ` Matt Fleming
2025-07-31 16:41 ` Alexei Starovoitov
2025-08-08 14:21 ` Matt Fleming
2025-08-08 16:42 ` Alexei Starovoitov [this message]
2025-08-13 16:59 ` Jesper Dangaard Brouer
2025-08-08 15:51 ` Jesper Dangaard Brouer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAADnVQ+Q6qqz_kCibF6MGCOWAH4WH6XypYSCZjQzW7SP2yyodA@mail.gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=hawk@kernel.org \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=matt@readmodwrite.com \
--cc=mfleming@cloudflare.com \
--cc=netdev@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).