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 9E862A04B3; Mon, 16 Dec 2019 13:54:16 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E18D21BFAB; Mon, 16 Dec 2019 13:54:15 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 160C01BFAA for ; Mon, 16 Dec 2019 13:54:13 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Dec 2019 04:54:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,321,1571727600"; d="scan'208";a="217407751" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga003.jf.intel.com with ESMTP; 16 Dec 2019 04:54:12 -0800 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 16 Dec 2019 04:54:11 -0800 Received: from fmsmsx604.amr.corp.intel.com (10.18.126.84) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 16 Dec 2019 04:54:11 -0800 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Mon, 16 Dec 2019 04:54:11 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.59) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 16 Dec 2019 04:54:10 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nhue7ksXM1YZKwB6NDYRuKy0iZYtj5jEalt+iGjGOmGpTBbCsLWieiVUpNZ/9q4de+YpecAYSa9nEGsb/6aaGMdbpUW3r2x8lNEWBuUu13iiaaX5rcG1g1K/HYLRG0XiNPUTYVtFn8TF9Yhs13aaePneBVPgN9Cxlq72Tsq3cnbCQFihjcU69GtPAwFNNQdAe9JnnAIS2HNrLKxsVftZksHLjAs1Gw7TalDNXTq6urXoqMGn31+bF2sT1wIKelGY+oY4QK8zUC06yoy/LxJ3j3nFM4WDOLx0Smb9D5eSGOVuB0huUBbd+/rOP5/wSIiVqiywA8YSjCaVC0Y6KHKBKw== 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=YcQr0Ccvy4OegTDiG8/n3T4kHbiGt4Th8ONuTK93voA=; b=CvhaAA7gRaVq5/9Tm0oErbThK+Q2N7w1r1SWa/M646YmaXhLTkB5pJ3n3GPPlwtS5vUHYR1Ko5L9Ri5qtVyJKsuBiLvlHzvZTrAFCRTgn4WtXbABMHgOFTCYbuEKGxeiqvOYKrWA0vpbfoiySApVU4jxjdY2WklfUWV0lPVC6qY1VfsMJvMvyUBVboCBh9Kz4nzqStPzwzAV3r6qui19p+/+qbRS/T1kL3EczVx5SDiDLXgOGpulUK7ZbEhCALA1o/eFxEuBxO9p5c2kjcWmaPPZMgFnKxqDusKKwIYyKE4NFn46gLHt6fe8PUBgK4HNnXFx9n29NOd2MrE3cNNHjw== 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=YcQr0Ccvy4OegTDiG8/n3T4kHbiGt4Th8ONuTK93voA=; b=MapT8siTbmGHCcsznEHXLNnNju4J5gj6q7VdjmgTdN44XPlDwydZDC/fqoPaum4bEy00bjasmTIRj9tCzVroAseIOtLuy9mp3CNB4Yl1VtYwHzM9Bn1bsWXpzWCVwLsNxKW8VBuiTRXSAIa/OUvU2CsmOcKif5kfBTJP2xC2lpk= Received: from SN6PR11MB2558.namprd11.prod.outlook.com (52.135.94.19) by SN6PR11MB3374.namprd11.prod.outlook.com (52.135.109.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.18; Mon, 16 Dec 2019 12:54:08 +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.019; Mon, 16 Dec 2019 12:54:08 +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: AQHVrbU6Hm2DnT5vjU6vDGoMxULIsaexx8cAgAAN7QCAAvJkUIAAbqqAgALCw8CAAsb0gIAB/4FA Date: Mon, 16 Dec 2019 12:54:08 +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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMWQ2MGEwZmQtY2FkMC00NzllLTkyMjYtYmY3YzIzZGFjOTM5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoid0lhdXB2bWJYV3Q5aTV4M3pyaldPTk00VTFTSXVkalN3bnNnM1JhdFNhWGFCQk9yZlwvUjVzQ0F0U09kRlZGVVYifQ== 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: 66189e54-dbac-41a8-2710-08d782270a3e x-ms-traffictypediagnostic: SN6PR11MB3374: 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:913; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(366004)(346002)(136003)(189003)(199004)(4326008)(6506007)(66446008)(7696005)(55016002)(9686003)(478600001)(110136005)(186003)(316002)(54906003)(5660300002)(81166006)(8676002)(8936002)(7416002)(33656002)(81156014)(86362001)(71200400001)(64756008)(66946007)(66556008)(76116006)(52536014)(15650500001)(26005)(2906002)(66476007); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR11MB3374; 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: 5q1MjFixTFbnTFTTjF4bh4lxdatlyeNl98vQ4FuTaFDJ7YaQW+7BeEUkbLX7wAkhI0S/Fl1IsZQgZEpSPY3nMC54LRehps5XHUzfhEGx1pkvxn7GBYssiul89KLgGuqi3+Memba+/TenHIHRAXPBlTdnGZcYc4caI6/M7i0u5zjsrgeitTuTeFPgxlH9E1eOkIPN4kDU/0l3ak3cFyLhAQ5uHPO91i8LaxtU2bvpWyfcKvv5buJvD4jM4A+EsDAw2AEnyCDkX5quuZs1q65Fk1Qa2VGLSox4uexZJHIDnISmJuIZ44eM7sIZalNEhM5+9kVgjgp5KHhhXbF1yAHU9ax0QjV9b5Ith8oqQ/ynyQynbD1QPyIuuM4tMS8tDk06nim6JCKRP5K7/f64T8MbzHBeasW02U/zIP0LZLoOQ0dDtKvrEPMPh1MCRctBDbdR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 66189e54-dbac-41a8-2710-08d782270a3e X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2019 12:54:08.1296 (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: pCxoqXs/NSICYcbk38SlUwzG4r71pJZXofBpbyBDYv1CgtbJNskw7eGgSRo38BWmpN8hI6qxE5VJrvSIfetBOBJtfS6HvmqjCEGpSmd6jfg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3374 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 inbound 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 wit= h > > > > > the 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 field 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 somehow passed via rte_flow API? > > > > If yes, then what would be the mechanism? > > > > > > [Anoob] I'm not sure what exactly you meant by user. But may be I'll = explain > > how it's done in OCTEONTX2 PMD. > > > > > > The application would create security_session for every SA. SPI etc w= ould 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 configu= re and > > h/w would have the pointer after the initialization is done. > > > > > > PMD uses SPI as index to write into specific locations(during session > > > create) 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). >=20 > [Anoob] Yes. >=20 > > 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? >=20 > [Anoob] Yes. >=20 > > Now if upper layer (ipsec-secgw for example) would like to create new E= SP > > session 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 thi= s HW/SW > > table for it? >=20 > [Anoob] rte_security_session_create() is enough. Then probably a stupid question:=20 If this HW/SW table will be created at dev_init() and to populate it rte_security_session_create() is sufficient, =20 why do you need that dummy flow at all? Would it be just used as a switch to enable/disable HW IPsec packet process= ing (either per whole device, or for some sub-ranges of SPI/SIP/DIP)? Something different? Konstantin=20 >=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 proposed > > > > change is to allow more efficient usage of h/w resources where it's > > > > permitted by the PMD. > > > > > > > > > > > > > > > > > > > > > > > > > Application should do an rte_flow_validate() to make sure the > > > > > > > flow 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= session. > > > > > > > + * > > > > > > > + * 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 > > > > > > > + items '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 > > structure. > > > > > > > */ > > > > > > > -- > > > > > > > 2.7.4