From: Martin KaFai Lau <martin.lau@linux.dev>
To: Vadim Fedorenko <vadfed@meta.com>, Eduard Zingerman <eddyz87@gmail.com>
Cc: bpf@vger.kernel.org, Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Andrii Nakryiko <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Mykola Lysenko <mykolal@fb.com>, Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH bpf-next v2 4/4] selftests: bpf: crypto: adjust bench to use nullable IV
Date: Wed, 22 May 2024 11:01:23 -0700 [thread overview]
Message-ID: <73add1b3-b1e4-4d83-85b3-5be45f2658d6@linux.dev> (raw)
In-Reply-To: <20240510122823.1530682-5-vadfed@meta.com>
On 5/10/24 5:28 AM, Vadim Fedorenko wrote:
> The bench shows some improvements, around 4% faster on decrypt.
The original intention is to make the crypto kfunc more ergonomic to use such
that the bpf prog does not have to initialize a zero length dynptr for the
optional dynptr argument.
This performance boost is a decent surprise considering the crypto operation
should be pretty heavy. (thanks for having the crypto benchmark handy).
Do you have a chance to get a perf record to confirm where the cycles is saved?
Why it only helps decrypt?
Inlining it would be nice (as Eduard mentioned in another thread). I also wonder
if Eduard's work on the no caller saved registers could help the dynptr kfunc? I
think the dynptr kfunc optimization could be a followup.
>
> Before:
>
> Benchmark 'crypto-decrypt' started.
> Iter 0 (325.719us): hits 5.105M/s ( 5.105M/prod), drops 0.000M/s, total operations 5.105M/s
> Iter 1 (-17.295us): hits 5.224M/s ( 5.224M/prod), drops 0.000M/s, total operations 5.224M/s
> Iter 2 ( 5.504us): hits 4.630M/s ( 4.630M/prod), drops 0.000M/s, total operations 4.630M/s
> Iter 3 ( 9.239us): hits 5.148M/s ( 5.148M/prod), drops 0.000M/s, total operations 5.148M/s
> Iter 4 ( 37.885us): hits 5.198M/s ( 5.198M/prod), drops 0.000M/s, total operations 5.198M/s
> Iter 5 (-53.282us): hits 5.167M/s ( 5.167M/prod), drops 0.000M/s, total operations 5.167M/s
> Iter 6 (-17.809us): hits 5.186M/s ( 5.186M/prod), drops 0.000M/s, total operations 5.186M/s
> Summary: hits 5.092 ± 0.228M/s ( 5.092M/prod), drops 0.000 ±0.000M/s, total operations 5.092 ± 0.228M/s
>
> After:
>
> Benchmark 'crypto-decrypt' started.
> Iter 0 (268.912us): hits 5.312M/s ( 5.312M/prod), drops 0.000M/s, total operations 5.312M/s
> Iter 1 (124.869us): hits 5.354M/s ( 5.354M/prod), drops 0.000M/s, total operations 5.354M/s
> Iter 2 (-36.801us): hits 5.334M/s ( 5.334M/prod), drops 0.000M/s, total operations 5.334M/s
> Iter 3 (254.628us): hits 5.334M/s ( 5.334M/prod), drops 0.000M/s, total operations 5.334M/s
> Iter 4 (-77.691us): hits 5.275M/s ( 5.275M/prod), drops 0.000M/s, total operations 5.275M/s
> Iter 5 (-164.510us): hits 5.313M/s ( 5.313M/prod), drops 0.000M/s, total operations 5.313M/s
> Iter 6 (-81.376us): hits 5.346M/s ( 5.346M/prod), drops 0.000M/s, total operations 5.346M/s
> Summary: hits 5.326 ± 0.029M/s ( 5.326M/prod), drops 0.000 ±0.000M/s, total operations 5.326 ± 0.029M/s
>
> Signed-off-by: Vadim Fedorenko <vadfed@meta.com>
> ---
> tools/testing/selftests/bpf/progs/crypto_bench.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/progs/crypto_bench.c b/tools/testing/selftests/bpf/progs/crypto_bench.c
> index e61fe0882293..4ac956b26240 100644
> --- a/tools/testing/selftests/bpf/progs/crypto_bench.c
> +++ b/tools/testing/selftests/bpf/progs/crypto_bench.c
> @@ -57,7 +57,7 @@ int crypto_encrypt(struct __sk_buff *skb)
> {
> struct __crypto_ctx_value *v;
> struct bpf_crypto_ctx *ctx;
> - struct bpf_dynptr psrc, pdst, iv;
> + struct bpf_dynptr psrc, pdst;
>
> v = crypto_ctx_value_lookup();
> if (!v) {
> @@ -73,9 +73,8 @@ int crypto_encrypt(struct __sk_buff *skb)
>
> bpf_dynptr_from_skb(skb, 0, &psrc);
> bpf_dynptr_from_mem(dst, len, 0, &pdst);
> - bpf_dynptr_from_mem(dst, 0, 0, &iv);
>
> - status = bpf_crypto_encrypt(ctx, &psrc, &pdst, &iv);
> + status = bpf_crypto_encrypt(ctx, &psrc, &pdst, NULL);
> __sync_add_and_fetch(&hits, 1);
>
> return 0;
> @@ -84,7 +83,7 @@ int crypto_encrypt(struct __sk_buff *skb)
> SEC("tc")
> int crypto_decrypt(struct __sk_buff *skb)
> {
> - struct bpf_dynptr psrc, pdst, iv;
> + struct bpf_dynptr psrc, pdst;
> struct __crypto_ctx_value *v;
> struct bpf_crypto_ctx *ctx;
>
> @@ -98,9 +97,8 @@ int crypto_decrypt(struct __sk_buff *skb)
>
> bpf_dynptr_from_skb(skb, 0, &psrc);
> bpf_dynptr_from_mem(dst, len, 0, &pdst);
> - bpf_dynptr_from_mem(dst, 0, 0, &iv);
>
> - status = bpf_crypto_decrypt(ctx, &psrc, &pdst, &iv);
> + status = bpf_crypto_decrypt(ctx, &psrc, &pdst, NULL);
> __sync_add_and_fetch(&hits, 1);
>
> return 0;
next prev parent reply other threads:[~2024-05-22 18:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 12:28 [PATCH bpf-next v2 0/4] bpf: make trusted args nullable Vadim Fedorenko
2024-05-10 12:28 ` [PATCH bpf-next v2 1/4] bpf: verifier: make kfuncs args nullalble Vadim Fedorenko
2024-05-21 19:48 ` Eduard Zingerman
2024-05-10 12:28 ` [PATCH bpf-next v2 2/4] bpf: crypto: make state and IV dynptr nullable Vadim Fedorenko
2024-05-21 19:48 ` Eduard Zingerman
2024-05-10 12:28 ` [PATCH bpf-next v2 3/4] selftests: bpf: crypto: use NULL instead of 0-sized dynptr Vadim Fedorenko
2024-05-21 19:48 ` Eduard Zingerman
2024-05-10 12:28 ` [PATCH bpf-next v2 4/4] selftests: bpf: crypto: adjust bench to use nullable IV Vadim Fedorenko
2024-05-21 19:49 ` Eduard Zingerman
2024-05-22 18:01 ` Martin KaFai Lau [this message]
2024-05-22 18:07 ` Eduard Zingerman
2024-05-22 21:18 ` Vadim Fedorenko
2024-05-21 19:46 ` [PATCH bpf-next v2 0/4] bpf: make trusted args nullable Eduard Zingerman
[not found] ` <912ac775-1505-468b-9030-88cbbf8e30f2@linux.dev>
[not found] ` <836e4a4ca07872fed42c0b2327dddecf47c572c0.camel@gmail.com>
2024-05-22 16:34 ` Vadim Fedorenko
2024-05-22 18:06 ` Martin KaFai Lau
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=73add1b3-b1e4-4d83-85b3-5be45f2658d6@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=eddyz87@gmail.com \
--cc=kuba@kernel.org \
--cc=mykolal@fb.com \
--cc=vadfed@meta.com \
--cc=vadim.fedorenko@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.