[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM6PR13MB3705F170F1EB28EE34F0C503FC3E9@DM6PR13MB3705.namprd13.prod.outlook.com>
Date: Wed, 9 Nov 2022 06:58:44 +0000
From: Yinjun Zhang <yinjun.zhang@...igine.com>
To: Leon Romanovsky <leon@...nel.org>
CC: David Miller <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Steffen Klassert <steffen.klassert@...unet.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Chengtian Liu <chengtian.liu@...igine.com>,
HuanHuan Wang <huanhuan.wang@...igine.com>,
Louis Peens <louis.peens@...igine.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
oss-drivers <oss-drivers@...igine.com>,
Simon Horman <simon.horman@...igine.com>
Subject: RE: [PATCH net-next v3 3/3] nfp: implement xfrm callbacks and expose
ipsec offload feature to upper layer
On Mon, 7 Nov 2022 08:14:12 +0200, Leon Romanovsky wrote:
> On Tue, Nov 01, 2022 at 12:02:48PM +0100, Simon Horman wrote:
<...>
> > +
> > + /* General */
> > + switch (x->props.mode) {
> > + case XFRM_MODE_TUNNEL:
> > + cfg->ctrl_word.mode = NFP_IPSEC_PROTMODE_TUNNEL;
> > + break;
> > + case XFRM_MODE_TRANSPORT:
> > + cfg->ctrl_word.mode = NFP_IPSEC_PROTMODE_TRANSPORT;
> > + break;
> > + default:
> > + nn_err(nn, "Unsupported mode for xfrm offload\n");
>
> There are no other modes.
Sorry this comment was neglected, but I have to say this is a good practice to avoid
newly introduced mode in future sneaking into HW while it's not supported.
Powered by blists - more mailing lists