All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Protopopov <aspsk@isovalent.com>
To: Martin KaFai Lau <martin.lau@linux.dev>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>
Subject: Re: [PATCH bpf-next 6/6] selftest/bpf/benchs: Add benchmark for hashmap lookups
Date: Tue, 31 Jan 2023 12:05:53 +0100	[thread overview]
Message-ID: <Y9j2EccwJnOsiFuV@lavr> (raw)
In-Reply-To: <23c1f484-380a-c112-86a1-5e104fb981f9@linux.dev>

On 23/01/30 04:22, Martin KaFai Lau wrote:
> On 1/27/23 10:14 AM, Anton Protopopov wrote:
> > +/* The number of slots to store times */
> > +#define NR_SLOTS 32
> > +
> > +/* Configured by userspace */
> > +u64 nr_entries;
> > +u64 nr_loops;
> > +u32 __attribute__((__aligned__(8))) key[256];
> > +
> > +/* Filled by us */
> > +u64 __attribute__((__aligned__(256))) percpu_times_index[NR_SLOTS]; > +u64 __attribute__((__aligned__(256))) percpu_times[256][NR_SLOTS];
> > +
> > +static inline void patch_key(u32 i)
> > +{
> > +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> > +	key[0] = i + 1;
> > +#else
> > +	key[0] = __builtin_bswap32(i + 1);
> > +#endif
> > +	/* the rest of key is random and is configured by userspace */
> > +}
> > +
> > +static int lookup_callback(__u32 index, u32 *unused)
> > +{
> > +	patch_key(index);
> > +	return bpf_map_lookup_elem(&hash_map_bench, key) ? 0 : 1;
> > +}
> > +
> > +static int loop_lookup_callback(__u32 index, u32 *unused)
> > +{
> > +	return bpf_loop(nr_entries, lookup_callback, NULL, 0) ? 0 : 1;
> > +}
> > +
> > +SEC("fentry/" SYS_PREFIX "sys_getpgid")
> > +int benchmark(void *ctx)
> > +{
> > +	u32 cpu = bpf_get_smp_processor_id();
> > +	u32 times_index;
> > +	u64 start_time;
> > +
> > +	times_index = percpu_times_index[cpu & 255] % NR_SLOTS;
> 
> percpu_times_index only has NR_SLOTS (32) elements?

Yes, the idea was the following. One measurement (bpf prog execution) takes
about 20-80 ms (depending on the key/map size). So in 2-3 seconds we can get
about NR_SLOTS elements. For me 32 looked like enough to get stats for this
benchmark. Do you think this is better to make the NR_SLOTS
bigger/configurable?

> > +	start_time = bpf_ktime_get_ns();
> > +	bpf_loop(nr_loops, loop_lookup_callback, NULL, 0);
> > +	percpu_times[cpu & 255][times_index] = bpf_ktime_get_ns() - start_time;
> > +	percpu_times_index[cpu & 255] += 1;
> > +	return 0;
> > +}
> 

  reply	other threads:[~2023-01-31 11:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27 18:14 [PATCH bpf-next 0/6] New benchmark for hashmap lookups Anton Protopopov
2023-01-27 18:14 ` [PATCH bpf-next 1/6] selftest/bpf/benchs: fix a typo in bpf_hashmap_full_update Anton Protopopov
2023-01-27 18:14 ` [PATCH bpf-next 2/6] selftest/bpf/benchs: make a function static " Anton Protopopov
2023-01-27 18:14 ` [PATCH bpf-next 3/6] selftest/bpf/benchs: enhance argp parsing Anton Protopopov
2023-01-31  0:07   ` Andrii Nakryiko
2023-01-31 13:35     ` Anton Protopopov
2023-01-27 18:14 ` [PATCH bpf-next 4/6] selftest/bpf/benchs: make quiet option common Anton Protopopov
2023-01-31  0:10   ` Andrii Nakryiko
2023-01-31 10:57     ` Anton Protopopov
2023-01-31 18:51       ` Andrii Nakryiko
2023-01-31 18:57       ` Anton Protopopov
2023-01-27 18:14 ` [PATCH bpf-next 5/6] selftest/bpf/benchs: print less if the quiet option is set Anton Protopopov
2023-01-27 18:14 ` [PATCH bpf-next 6/6] selftest/bpf/benchs: Add benchmark for hashmap lookups Anton Protopopov
2023-01-31  0:16   ` Andrii Nakryiko
2023-01-31 11:01     ` Anton Protopopov
2023-01-31  0:22   ` Martin KaFai Lau
2023-01-31 11:05     ` Anton Protopopov [this message]
2023-01-31 22:50       ` Martin KaFai Lau
2023-02-01  9:12         ` Anton Protopopov
2023-01-31  0:17 ` [PATCH bpf-next 0/6] New " Andrii Nakryiko
2023-01-31 10:47   ` Anton Protopopov
2023-01-31 18:48     ` Andrii Nakryiko
2023-01-31 19:18       ` Anton Protopopov
2023-02-01  0:02         ` Andrii Nakryiko
2023-02-01  9:41           ` Anton Protopopov

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=Y9j2EccwJnOsiFuV@lavr \
    --to=aspsk@isovalent.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=martin.lau@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.