BPF List
 help / color / mirror / Atom feed
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;


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox