From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 42E42A04F1;
Fri, 13 Dec 2019 12:55:30 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id DE1511BE8E;
Fri, 13 Dec 2019 12:55:28 +0100 (CET)
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
by dpdk.org (Postfix) with ESMTP id 157011BE8A
for <dev@dpdk.org>; Fri, 13 Dec 2019 12:55:26 +0100 (CET)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga006.fm.intel.com ([10.253.24.20])
by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
13 Dec 2019 03:55:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.69,309,1571727600"; d="scan'208";a="415619121"
Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202])
by fmsmga006.fm.intel.com with ESMTP; 13 Dec 2019 03:55:25 -0800
Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by
fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS)
id 14.3.439.0; Fri, 13 Dec 2019 03:55:25 -0800
Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by
fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS)
id 14.3.439.0; Fri, 13 Dec 2019 03:55:25 -0800
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.172)
by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id
14.3.439.0; Fri, 13 Dec 2019 03:55:25 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=jIu5p6MoVFLn0RiGRIeFuA7VlomiyjWehvtmj/RCzbk6AILp1ToAdXJQJOt2YL6s7dHfFD6GPGHp2QsH29s+pKDKMG0m0mWIaTjfotrNk/FqwJI8PkQO33kCIRABP6B9DWb6fbUFfeEOhvhH9qza9fJw3Mc2+CUK/bMwyGf1hH9/PdI8J2gUBO/3ipj2svIjAMHoClEC82gyVtZaxcCd/W8Cw8hI/wfGvMT7/6O93prZqP4VcpM/fc7Hl8w74+WzXGwaUPecm/kpH/6i6FBDDf7dAYCGzyL4Q/9ix/A0h+DbbbrNUGFod5/MhQtCVkUQm+iStkRKVDSeAyUa5/1zgQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=Jie0oJ+5mq7Bw35vC6fyfQCoxKOoU+zimywM4wyvuGk=;
b=UaPXA1Y8JpcrBSNuXTuc5jR1maN414NZ4U3CBW84lbEI3yVavLB2nPrYoHKZWYYEmdQPXo9I3CMIksM/eXEcpl8TmJXpSDTvvGNBN83ndHV5BxFDhPZr3zCt7gzoDZ4uVHgNaKyH4T6tLj/cEO9h4wvGANRqP7HaHzaIJ15x+XRO+5x7X0NFD0XVDUvHv84et5UWkI2xQRldsaoi60pAyQaNN+K0Y/gQ5Z5gpaGNLzbnUGm6ek3MeDcKIYNJ438HXYGXnAm0TXLQ4XY0HC5AOMW3aa/fG1mab74dskOlbmbVQyaCJ/rRrW3rk7JI7oujmwphp71QhWF3wbU7/hhsYQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;
dkim=pass header.d=intel.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;
s=selector2-intel-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=Jie0oJ+5mq7Bw35vC6fyfQCoxKOoU+zimywM4wyvuGk=;
b=vGxZVTy/9ItoxeB5ilPtUPst5+pXvRGkjxQmpSdS98wfvLQb9IpgrbxUG9U2ryNf+GXFKD4T8QYpkQjemSxL5Jvb3YnWnBwzoUsDvf+WkasiPs2xafcDVRvJww1UkcStnvXZojogz6HMjMmkDa+GsXGrY8Slsz+soBEox1SNnBg=
Received: from SN6PR11MB2558.namprd11.prod.outlook.com (52.135.94.19) by
SN6PR11MB2701.namprd11.prod.outlook.com (52.135.89.158) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.2538.18; Fri, 13 Dec 2019 11:55:23 +0000
Received: from SN6PR11MB2558.namprd11.prod.outlook.com
([fe80::4d86:362a:13c3:8386]) by SN6PR11MB2558.namprd11.prod.outlook.com
([fe80::4d86:362a:13c3:8386%7]) with mapi id 15.20.2538.016; Fri, 13 Dec 2019
11:55:23 +0000
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Anoob Joseph <anoobj@marvell.com>, Akhil Goyal <akhil.goyal@nxp.com>,
Adrien Mazarguil <adrien.mazarguil@6wind.com>, "Doherty, Declan"
<declan.doherty@intel.com>, "Yigit, Ferruh" <ferruh.yigit@intel.com>, "Jerin
Jacob Kollanukkaran" <jerinj@marvell.com>, Thomas Monjalon
<thomas@monjalon.net>
CC: Ankur Dwivedi <adwivedi@marvell.com>, Hemant Agrawal
<hemant.agrawal@nxp.com>, Matan Azrad <matan@mellanox.com>, "Nicolau, Radu"
<radu.nicolau@intel.com>, Shahaf Shuler <shahafs@mellanox.com>, "Narayana
Prasad Raju Athreya" <pathreya@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [PATCH] ethdev: allow multiple security sessions to use one rte
flow
Thread-Index: AQHVrbU6Hm2DnT5vjU6vDGoMxULIsaexx8cAgAAN7QCAAvJkUIAAbqqAgALCw8A=
Date: Fri, 13 Dec 2019 11:55:22 +0000
Message-ID: <SN6PR11MB255846243549454A017D83A49A540@SN6PR11MB2558.namprd11.prod.outlook.com>
References: <1575801683-27269-1-git-send-email-anoobj@marvell.com>
<BN7PR11MB25478BD0152762D4CB1E16FC9A580@BN7PR11MB2547.namprd11.prod.outlook.com>
<MN2PR18MB2877B0C35B11432B9FA02452DF580@MN2PR18MB2877.namprd18.prod.outlook.com>
<BN7PR11MB2547EAF3CE86AAE432F903E29A5A0@BN7PR11MB2547.namprd11.prod.outlook.com>
<MN2PR18MB2877C4D70B32ECDFED9F82E8DF5A0@MN2PR18MB2877.namprd18.prod.outlook.com>
In-Reply-To: <MN2PR18MB2877C4D70B32ECDFED9F82E8DF5A0@MN2PR18MB2877.namprd18.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNWNiM2M4NzctNzU1MS00OGNiLWFlNzctYWM2NzVlODZhOTExIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNzBTaitlbXJ0OXFsMEZoRjVueWtwRkVPeGtjcHN6aDhsUm1oQ0pwQjdCZHNwanYyam04OUhIMUcwaDVpckVDeiJ9
dlp-product: dlpe-windows
dlp-reaction: no-action
dlp-version: 11.2.0.6
x-ctpclassification: CTP_NT
authentication-results: spf=none (sender IP is )
smtp.mailfrom=konstantin.ananyev@intel.com;
x-originating-ip: [192.198.151.184]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5291dc39-2e5f-4ae1-c6f5-08d77fc355f5
x-ms-traffictypediagnostic: SN6PR11MB2701:
x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <SN6PR11MB2701E2D18CD0BB34EB8A28D89A540@SN6PR11MB2701.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-forefront-prvs: 0250B840C1
x-forefront-antispam-report: SFV:NSPM;
SFS:(10019020)(346002)(136003)(366004)(396003)(376002)(39860400002)(189003)(199004)(71200400001)(2906002)(86362001)(52536014)(26005)(5660300002)(7696005)(6506007)(81156014)(15650500001)(81166006)(186003)(55016002)(4326008)(8676002)(7416002)(9686003)(110136005)(54906003)(478600001)(76116006)(66476007)(64756008)(66556008)(316002)(8936002)(66446008)(33656002)(66946007);
DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR11MB2701;
H:SN6PR11MB2558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en;
PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5J0ETjfw6MAOtRY9xQKmNsuqTJmbmMjT705D7hD63yW56Ws2VDt2+xqET3yoox2/lEIW0yYOHmgNQrzsvc5shCknATRS5pEapgoXriubghGZ7qBqzhKj8ZDJX3vUnOkobkUyb+4Pb+g2LqS/crIK3Rbroui8dVNMFSBbJFF0GuE9zmNSNIYquew+dNzhjKS0u1lejiV0jZFgcc4ClU0ee0DnhvuAj/bVlFP3sl0/hTZ3YlYFu2EA/x8nLOhr8814zJ1ElII2J2PI/bhPNFa5ll894KBr28xjRUfQbFpZeDkwm84upQFydEJQuGxE02Je1uPrbswswqEhM/V16BaFFKv2NGsKpPTESOgjBMdbZzSi4icFN9EcucmOyZOAJ9V1S5HNNAW5QtmmSru5XB49F8VAJ5yvQx3tfNxD4EYHMp1Y0q+uM9J4F8I2HNAhj7/A
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5291dc39-2e5f-4ae1-c6f5-08d77fc355f5
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2019 11:55:22.8588 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KGycb2JHwrfhLfMX6/wQ2Jp1umtGCKSbESmYygQ+BMcCojB7QbTTwqrF5iX8XEZjvM7zC03Jo7dg7gUgoAoGApoqoi6nAnDguGsCdT6hgQw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2701
X-OriginatorOrg: intel.com
Subject: Re: [dpdk-dev] [PATCH] ethdev: allow multiple security sessions to
use one rte flow
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
> > > > > The rte_security API which enables inline protocol/crypto feature
> > > > > mandates that for every security session an rte_flow is created.
> > > > > This would internally translate to a rule in the hardware which
> > > > > would do packet classification.
> > > > >
> > > > > In rte_securty, one SA would be one security session. And if an
> > > > > rte_flow need to be created for every session, the number of SAs
> > > > > supported by an inline implementation would be limited by the
> > > > > number of rte_flows the PMD would be able to support.
> > > > >
> > > > > If the fields SPI & IP addresses are allowed to be a range, then
> > > > > this limitation can be overcome. Multiple flows will be able to
> > > > > use one rule for SECURITY processing. In this case, the security
> > > > > session provided as conf would be NULL.
> > > >
> > > > Wonder what will be the usage model for it?
> > > > AFAIK, RFC 4301 clearly states that either SPI value alone or in
> > > > conjunction with dst (and src) IP should clearly identify SA for in=
bound SAD
> > lookup.
> > > > Am I missing something obvious here?
> > >
> > > [Anoob] Existing SECURITY action type requires application to create
> > > an 'rte_flow' per SA, which is not really required if h/w can use SPI=
to uniquely
> > identify the security session/SA.
> > >
> > > Existing rte_flow usage: IP (dst,src) + ESP + SPI -> security
> > > processing enabled on one security session (ie on SA)
> > >
> > > The above rule would uniquely identify packets for an SA. But with th=
e
> > > above usage, we would quickly exhaust entries available in h/w lookup
> > > tables (which are limited on our hardware). But if h/w can use SPI fi=
eld to index
> > into a table (for example), then the above requirement of one rte_flow =
per SA is
> > not required.
> > >
> > > Proposed rte_flow usage: IP (any) + ESP + SPI (any) -> security
> > > processing enabled on all ESP packets
> > >
> > > Now h/w could use SPI to index into a pre-populated table to get
> > > security session. Please do note that, SPI is not ignored during the =
actual
> > lookup. Just that it is not used while creating 'rte_flow'.
> >
> > And this table will be prepopulated by user and pointer to it will be s=
omehow
> > passed via rte_flow API?
> > If yes, then what would be the mechanism?
>=20
> [Anoob] I'm not sure what exactly you meant by user. But may be I'll expl=
ain how it's done in OCTEONTX2 PMD.
>=20
> The application would create security_session for every SA. SPI etc would=
be available to PMD (in conf) when the session is created.
> Now the PMD would populate SA related params in a specific location that =
h/w would access. This memory is allocated during device
> configure and h/w would have the pointer after the initialization is done=
.
>=20
> PMD uses SPI as index to write into specific locations(during session cre=
ate) and h/w would use it when it sees an ESP packet eligible
> for SECURITY (in receive path, per packet). As long as session creation c=
ould populate at memory locations that h/w would look at, this
> scheme would work.
Thanks for explanation, few more questions:
Ok, so the table will be allocated at device init() somehow (nothing to do =
with rte_flow).
Then PMD will be able to write/update entries in that table and HW will be =
able to read (to get SPI, keys, etc), correct?
Now if upper layer (ipsec-secgw for example) would like to create new ESP s=
ession on that device, what it would need to do?
Would it still need to use rte_flow API for that?
Or just call rte_security_session_create() and PMD will take update this HW=
/SW table for it?
>=20
> >
> > >
> > > The usage of one 'rte_flow' for multiple SAs is not mandatory. It is
> > > only required when application requires large number of SAs. The prop=
osed
> > change is to allow more efficient usage of h/w resources where it's per=
mitted by
> > the PMD.
> > >
> > > >
> > > > >
> > > > > Application should do an rte_flow_validate() to make sure the flo=
w
> > > > > is supported on the PMD.
> > > > >
> > > > > Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> > > > > ---
> > > > > lib/librte_ethdev/rte_flow.h | 6 ++++++
> > > > > 1 file changed, 6 insertions(+)
> > > > >
> > > > > diff --git a/lib/librte_ethdev/rte_flow.h
> > > > > b/lib/librte_ethdev/rte_flow.h index 452d359..21fa7ed 100644
> > > > > --- a/lib/librte_ethdev/rte_flow.h
> > > > > +++ b/lib/librte_ethdev/rte_flow.h
> > > > > @@ -2239,6 +2239,12 @@ struct rte_flow_action_meter {
> > > > > * direction.
> > > > > *
> > > > > * Multiple flows can be configured to use the same security ses=
sion.
> > > > > + *
> > > > > + * The NULL value is allowed for security session. If security
> > > > > + session is NULL,
> > > > > + * then SPI field in ESP flow item and IP addresses in flow item=
s
> > > > > + 'IPv4' and
> > > > > + * 'IPv6' will be allowed to be a range. The rule thus created
> > > > > + can enable
> > > > > + * SECURITY processing on multiple flows.
> > > > > + *
> > > > > */
> > > > > struct rte_flow_action_security {
> > > > > void *security_session; /**< Pointer to security session struct=
ure.
> > > > > */
> > > > > --
> > > > > 2.7.4