[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQJ7__C06a=v0RfMvGQ_ohT21n=-1EUuaxqBe3aYU1izEg@mail.gmail.com>
Date: Sat, 18 Nov 2023 15:35:24 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: Vadim Fedorenko <vadfed@...a.com>, Jakub Kicinski <kuba@...nel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>, Andrii Nakryiko <andrii@...nel.org>,
Alexei Starovoitov <ast@...nel.org>, Mykola Lysenko <mykolal@...com>,
Herbert Xu <herbert@...dor.apana.org.au>, Network Development <netdev@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP programs
On Sat, Nov 18, 2023 at 3:32 PM Vadim Fedorenko
<vadim.fedorenko@...ux.dev> wrote:
>
> On 18/11/2023 18:23, Alexei Starovoitov wrote:
> > On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <vadfed@...a.com> wrote:
> >>
> >> +/**
> >> + * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher context structure
> >> + * @tfm: The pointer to crypto_sync_skcipher struct.
> >> + * @rcu: The RCU head used to free the crypto context with RCU safety.
> >> + * @usage: Object reference counter. When the refcount goes to 0, the
> >> + * memory is released back to the BPF allocator, which provides
> >> + * RCU safety.
> >> + */
> >> +struct bpf_crypto_lskcipher_ctx {
> >> + struct crypto_lskcipher *tfm;
> >> + struct rcu_head rcu;
> >> + refcount_t usage;
> >> +};
> >> +
> >> +__bpf_kfunc_start_defs();
> >> +
> >> +/**
> >> + * bpf_crypto_lskcipher_ctx_create() - Create a mutable BPF crypto context.
> >
> > Let's drop 'lskcipher' from the kfunc names and ctx struct.
> > bpf users don't need to know the internal implementation details.
> > bpf_crypto_encrypt/decrypt() is clear enough.
>
> The only reason I added it was the existence of AEAD subset of crypto
> API. And this subset can also be implemented in bpf later, and there
> will be inconsistency in naming then if we add aead in future names.
> WDYT?
You mean future async apis ? Just bpf_crypto_encrypt_async() ?
Powered by blists - more mailing lists