[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZLfEnOO0bzgBfJFj@gauss3.secunet.de>
Date: Wed, 19 Jul 2023 13:10:20 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Yinjun Zhang <yinjun.zhang@...igine.com>
CC: Louis Peens <louis.peens@...igine.com>, David Miller
<davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Herbert Xu <herbert@...dor.apana.org.au>, "Leon
Romanovsky" <leon@...nel.org>, Simon Horman <simon.horman@...igine.com>,
Shihong Wang <shihong.wang@...hogine.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, oss-drivers <oss-drivers@...igine.com>
Subject: Re: [PATCH net-next 1/2] xfrm: add the description of
CHACHA20-POLY1305 for xfrm algorithm description
On Wed, Jul 19, 2023 at 10:52:03AM +0000, Yinjun Zhang wrote:
> On Wednesday, July 19, 2023 5:27 PM, Steffen Klassert wrote:
> > On Wed, Jul 19, 2023 at 11:18:29AM +0200, Louis Peens wrote:
> > > From: Shihong Wang <shihong.wang@...igine.com>
> > >
> > > Add the description of CHACHA20-POLY1305 for xfrm algorithm description
> > > and set pfkey_supported to 1 so that xfrm supports that the algorithm
> > > can be offloaded to the NIC.
> > >
> > > Signed-off-by: Shihong Wang <shihong.wang@...igine.com>
> > > Acked-by: Simon Horman <simon.horman@...igine.com>
> > > Signed-off-by: Louis Peens <louis.peens@...igine.com>
> > > ---
> > > include/uapi/linux/pfkeyv2.h | 1 +
> > > net/xfrm/xfrm_algo.c | 9 ++++++++-
> > > 2 files changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/uapi/linux/pfkeyv2.h b/include/uapi/linux/pfkeyv2.h
> > > index 8abae1f6749c..d0ab530e1069 100644
> > > --- a/include/uapi/linux/pfkeyv2.h
> > > +++ b/include/uapi/linux/pfkeyv2.h
> > > @@ -331,6 +331,7 @@ struct sadb_x_filter {
> > > #define SADB_X_EALG_CAMELLIACBC 22
> > > #define SADB_X_EALG_NULL_AES_GMAC 23
> > > #define SADB_X_EALG_SM4CBC 24
> > > +#define SADB_X_EALG_CHACHA20_POLY1305 25
> >
> > Please don't add new stuff to pfkey, use netlink instead. This interface
> > is deprecated and will go away someday.
>
> Sorry, we don't get it. How does driver know which algo it is without these
> definitions? Is there any document guide that we can refer to?
Ugh, I've just seen that you use this in the drivers. The correct way
would be to parse the name of the algorithm, as the crypto layer does
it.
Powered by blists - more mailing lists