From: Martin KaFai Lau <martin.lau@linux.dev>
To: Anton Protopopov <aspsk@isovalent.com>
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 14:50:24 -0800 [thread overview]
Message-ID: <6faf60d9-b125-2bde-715b-f0bd3b637777@linux.dev> (raw)
In-Reply-To: <Y9j2EccwJnOsiFuV@lavr>
On 1/31/23 3:05 AM, Anton Protopopov wrote:
> 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?
I thought percpu_times_index[] is the next slot to use for a particular cpu in
percpu_times[256][NR_SLOTS]. 256 is the max number of cpu supported? It is doing
"cpu" & 255 also. Should it be sized as percpu_times_index[256] instead then?
May be #define what 256 is here such that it can have a self describe name.
>
>>> + 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;
>>> +}
>>
next prev parent reply other threads:[~2023-01-31 22:50 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
2023-01-31 22:50 ` Martin KaFai Lau [this message]
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=6faf60d9-b125-2bde-715b-f0bd3b637777@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=aspsk@isovalent.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
/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