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 1CE0AA04F0; Mon, 16 Dec 2019 16:37:30 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 960182BB8; Mon, 16 Dec 2019 16:37:28 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id A62841F5 for ; Mon, 16 Dec 2019 16:37:27 +0100 (CET) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBGFaeh0026950; Mon, 16 Dec 2019 07:37:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=PmnkCuBwBDhaHJ0pIzHieG9CL9LOmfvhmDA3wri8CxU=; b=qh//UgONw00o6dIWUAkHDBBczuQqVHOymZ21W6LoE2kKRBFkI2hSOnuMCapnCv65oLbG ckAlarV1VXFUM7a0H/h2HfdxAghx29bawFSa/dBPaYyLTfZNGtLt7z0sy/HtqJAkoUWx gfsqpzzIAh6kIYOMr6NYllhG/DR/kusTZwYGmdCjfhGp8AatXkFFAn5al8siZtW3QmBj wKggGpj6+YlnJcbzTUThWd9HGl5xu27oVcsM+q9Y1W+TpYk5f+AWTjHm+r2DCqvSd/Iv Di4aOdTCv64bMF4JTWqa3cYeA/o0F0RUlX2zKBwu6Zes/fAnOpVowP6Le1ucThM9oFJJ gQ== Received: from sc-exch04.marvell.com ([199.233.58.184]) by mx0b-0016f401.pphosted.com with ESMTP id 2ww04tpg9v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 16 Dec 2019 07:37:26 -0800 Received: from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 16 Dec 2019 07:37:23 -0800 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.51) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 16 Dec 2019 07:37:23 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kXlyQmApl4jXjegm6XL3Gm9gOVLGM6KSXuOg4SYQt1lyn7gRxfvlnADlYljlFaAf0+bL5shFKIKZNsx2l4U7A3Xg/0dxjidQ++AGYDjY/Ngu1WcMpVAPK1+dyop00bUGWByy1cP4bZzuJfYKJfE1A1QoL0SyaAm36i0qh1RtvKG7rkQ102vW7OEhaLHbb9buxhNpRwEZLqoD55bDf8bPoj8ugC1q4FPOecZ3LCYw7RTaYln+xMbx3zPdnXsNo4WJ2nRoLTjOfVMpjyEC4QbXhcYnX8Gyd+KiHtbPOURmGHfF+R4EsbXDvDBYNGekWlOcc9ecNBXFxZJNtVEvmF3rBQ== 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=PmnkCuBwBDhaHJ0pIzHieG9CL9LOmfvhmDA3wri8CxU=; b=cbduS6rAhIm/9Jh4j9S6SirGhY3Cw5YmMs+o214B+ae0LH4VvNWZkOMxFwn5MrNMyf/pNiKVmEq09pGKT2WlnMaS+fUQbf0YPE/9+dXMbcBd3gLVWDBdqdlEmFBR5dUwX98KtnD9HsQHF5dyR7r4kqielrof/P+GjGMK0KUmNEDCEz67173oe7gRI+gfxL/sZWhkeVS5vF5SpzWGGgvMAd5s5k1ir60b4NeXMNBp/Fl6NecOYjAkWdFEG27cjrobvR57mLruIymftIfa3CPufAqQmdEnj4U31iHiKdrKsdf9oqEtykl/fwB5+dqJe9Nt1mOGeU9VWvBQfkq/vl/5ug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PmnkCuBwBDhaHJ0pIzHieG9CL9LOmfvhmDA3wri8CxU=; b=lHwQbTECNg4bSPiSyuXh6NftMiLjPUQIRuKbNnMXu2xLWzYN3AOWidXeMQq+Td2BIfP+76QGFQmLBQTiqnpyRWDYEnmpeGBXBLlonxltzX3kpEZroImhdd1KEQzLA3FuY1wffayVM/YwEhDmcug2RIY7MxdNSb3PkKElFjV+xNE= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB3070.namprd18.prod.outlook.com (20.178.255.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.19; Mon, 16 Dec 2019 15:37:22 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::358a:10f1:5e8e:f6f]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::358a:10f1:5e8e:f6f%7]) with mapi id 15.20.2538.019; Mon, 16 Dec 2019 15:37:22 +0000 From: Anoob Joseph To: "Ananyev, Konstantin" , 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: AQHVrpMvw4Myz8aLekOSWFJnfZYPsaexyb8AgAL/DQCAAFP3wIAC3nsAgALCnpCAAgTMAIAAKmww Date: Mon, 16 Dec 2019 15:37:22 +0000 Message-ID: References: <1575801683-27269-1-git-send-email-anoobj@marvell.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [111.125.206.217] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f5fbef4-0913-4522-fe1c-08d7823dd80a x-ms-traffictypediagnostic: MN2PR18MB3070: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:626; x-forefront-prvs: 02530BD3AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(366004)(376002)(39860400002)(346002)(13464003)(189003)(199004)(54906003)(81166006)(110136005)(5660300002)(81156014)(8936002)(478600001)(316002)(66946007)(66556008)(52536014)(15650500001)(76116006)(86362001)(55016002)(33656002)(53546011)(6506007)(4326008)(2906002)(55236004)(8676002)(7416002)(64756008)(186003)(9686003)(71200400001)(26005)(7696005)(66476007)(66446008)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB3070; H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Unqx5jlW97a1FO1mJfk23dXIl3z6C0sc06nbvCKYcfgx4BFJIvQbtfn+swP87BDpj+tww4VvZoDdDByG1+gX2TCjPlsRnVOrUMoE9JkwrEbW7nWpOpLGvEtHXpgfzEetrZg7k+v1zfbZp+y8DfBGnKEjL7L15Pcgkky8LFI9KuUj5MN9KB7vXUf8Lh++20F/TGZ/r4vmR59f5/2a2vc25BeVkwG9G2EfSJxoRjVLbDHylQNSp8RwjsdyzKsthGY4V2ApubO0JSc6/hBgNL4Xtapt/0UPa/2XzkILZYeYT1DjCk9krVG19ILTXHqz3p1o6/LeYQRa6XMsEfk1O5N0gEtOSmNlmxMjY2qRtBgwQYw93Tgs6TVjqq84XLFB1t7SVvaWE67YCw9DSsfPEd0sPZIWsgBGhkY4UlE5o4npocizssAv/PXdgXLizfyDz5uUePwrQFNsUzBYfaZaPRikk9NZqP9lGaZ0+1JAvTqWjmQj6B0Hv7VbxFYDylV1Ld21qNvVR5rs4CXFC0uATicTTQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2f5fbef4-0913-4522-fe1c-08d7823dd80a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2019 15:37:22.1791 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fDCONS7+Cy2iM1AhYs2oQRsFF1Uy5dQ7dS6he0OfUx7HOLsQ8lXFJxjJcT9d0MDCBuC3gQPcAG/4o+Fmtipd/A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3070 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-16_05:2019-12-16,2019-12-16 signatures=0 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" Hi Konstantin, Please see inline. Thanks, Anoob > -----Original Message----- > From: Ananyev, Konstantin > Sent: Monday, December 16, 2019 6:24 PM > 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 > Subject: [EXT] RE: [PATCH] ethdev: allow multiple security sessions to us= e one > rte flow >=20 > External Email >=20 > ---------------------------------------------------------------------- >=20 > > > > > > > > The rte_security API which enables inline protocol/crypto > > > > > > > > feature mandates that for every security session an rte_flo= w 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 > > > > > > with 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 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. > > > > > > > > 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 could > > > populate at memory locations that h/w would look at, this scheme woul= d > work. > > > > > > Thanks for explanation, few more questions: > > > Ok, so the table will be allocated at device init() somehow (nothing > > > to do with rte_flow). > > > > [Anoob] Yes. > > > > > 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? > > > > [Anoob] Yes. > > > > > Now if upper layer (ipsec-secgw for example) would like to create > > > new ESP 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 > > > this HW/SW table for it? > > > > [Anoob] rte_security_session_create() is enough. >=20 > Then probably a stupid question: > If this HW/SW table will be created at dev_init() and to populate it > rte_security_session_create() is sufficient, why do you need that dummy f= low at > all? > Would it be just used as a switch to enable/disable HW IPsec packet proce= ssing > (either per whole device, or for some sub-ranges of SPI/SIP/DIP)? > Something different? [Anoob] Your understanding is correct. rte_flow is used to selectively enab= le/disable HW IPsec processing.=20 =20 > Konstantin >=20 > > > > > > > > > > > > > > > > > > > > > > > > > > The usage of one 'rte_flow' for multiple SAs is not mandatory. > > > > > > It is only required when application requires large number of S= As. > > > > > > 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 securi= ty > 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