From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; 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" To: Anoob Joseph , Akhil Goyal , Adrien Mazarguil , "Doherty, Declan" , "Yigit, Ferruh" , "Jerin Jacob Kollanukkaran" , Thomas Monjalon CC: Ankur Dwivedi , Hemant Agrawal , Matan Azrad , "Nicolau, Radu" , Shahaf Shuler , "Narayana Prasad Raju Athreya" , "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: References: <1575801683-27269-1-git-send-email-anoobj@marvell.com> In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > > > > > 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 > > > > > --- > > > > > 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