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 81542A04F6; Wed, 11 Dec 2019 18:33:40 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8C4312C6A; Wed, 11 Dec 2019 18:33:39 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 0C73A91 for ; Wed, 11 Dec 2019 18:33:37 +0100 (CET) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xBBHQ665008645; Wed, 11 Dec 2019 09:33:35 -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=TsJZELqhXezXptjoIlGP9yxrE4XKR1/Gjkilz6y06yE=; b=F/FPZOWAjEbixSAlCNd6f+ECd8WO2gmkaubTVcpkB2qTJIHgIC3hS7tndmcG4D/T2Q0R 6r9vpEF89eZeIj+aEL63+jiWEvhnsQXzCVlWhtLYfDIfpAJAcjZw9B9CqcvamYaXELfB RtlQ6ZkF8Q9IyzTZjMN0YC3t8LSQpmj/GhFjsPMvKVIzi6iFV/zmq0HIBR5Ki24J0neo R3MxHzPUCVyz/c2dKQ4qdh2+oFc5G9ZjqULFUExqHX8B4FZqKcxGnyxSSYZTxUXFSA1V 6sCna8lqbFcmwjcC74emfAXxBfH9++EU4dscucONP2/tGKwrHJyTH6D2xynQdlk4MXMM XQ== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0a-0016f401.pphosted.com with ESMTP id 2wst5t24ke-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Dec 2019 09:33:35 -0800 Received: from SC-EXCH02.marvell.com (10.93.176.82) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 11 Dec 2019 09:33:31 -0800 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.55) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 11 Dec 2019 09:33:31 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TnQakYTEGdaayY1VJVI2u+BbwNcOR6yJ4oOyIvszrDzFV9pTxFD9O80Iu3wne3ItDZ++btWp3BpVDLWeN9xfHYel4cbgHJoY/M1Y3LOtna4QpnmGMvemAT79oroSRDJ0sETyiR16oI60XWGJB+fWU5SDmc1H2KGROeyiwvc6NA6dSLYWlLgnl8ZeARSfWKmMb5jzu+jqGvZluYhMKk77U3efyvCyAQnkX8y5+YTRoR7Ti0/IudNsIssTZXgHQm+q6bLHdnrjMk4hkYFlFvZQgB1HumHZourtEUwaPl6VSe5y8A5ivX8sLQb/sxl/Th7CJjmcwGc98ftnY0p3BWoUEA== 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=TsJZELqhXezXptjoIlGP9yxrE4XKR1/Gjkilz6y06yE=; b=eR9SR5pVP3l0eIebjlZE7BRSAiDrKsLCRW3xvHQHbBd86b0RgAzocITK1W1E/7+6IMN98OX0G0bU/rX+OG9rVXMMD5wyJon+joU7ygJIJMixg6Qk7nqw4WyLjHaYB0Gy/30bS64BHhEckm4QopKw0kJP3H/rAwPohlZ3r8WpGnbT5XfQKp+yz5fsg4KQABvvy9wNFGV8IoIQ7sHubJPvV3d9Q0xRp7U9VZHxDyS51ZKbfAE4EB9h6p+xwrl0+k6/e56jtlf8JkQh6nunnnsypa6oikz63bXgpnm1QCMAFfRGDjjYIHKIbilWVc2p1HeYgpzeNRVTDyLtzhcNMhsN4Q== 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=TsJZELqhXezXptjoIlGP9yxrE4XKR1/Gjkilz6y06yE=; b=tmby4B4HFGuaTlvOMrpKtmCa7OIE4zqZA0Zgi0kXld388qGNo1nO7BfEMIYqp5MdG7X0HUOSWHaO3IF9yluy11wDcPmAtndypfvY7hEDNbZmHDiC/HDEb2uK3AHdPa0E32Tg3D4aBP1QpkwcGZa5T+CeeoMrzkYBkxXr8xk3QgA= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB2448.namprd18.prod.outlook.com (20.179.82.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2538.16; Wed, 11 Dec 2019 17:33:24 +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.016; Wed, 11 Dec 2019 17:33:24 +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/DQCAAFP3wA== Date: Wed, 11 Dec 2019 17:33:23 +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.192.33] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f8f672d-ccb1-4499-11cc-08d77e603969 x-ms-traffictypediagnostic: MN2PR18MB2448: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(39860400002)(376002)(396003)(366004)(13464003)(199004)(189003)(2906002)(66946007)(6506007)(55236004)(66476007)(186003)(76116006)(26005)(54906003)(33656002)(64756008)(66556008)(316002)(66446008)(53546011)(9686003)(15650500001)(110136005)(7416002)(86362001)(55016002)(8936002)(7696005)(81166006)(478600001)(81156014)(52536014)(71200400001)(8676002)(4326008)(5660300002)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2448; H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: TOpxsCD5ie4aAlkaXf50vwUWeLwh3AJ+SDl3z8rmOvuTfXI3eA16NP5n4FM/5NsWl675cxA6oYO0UxYrHCGiWOqcaQ1CXA2NWi0WWL+gRsRqku6muh+4HlPZiQ0tZDqYqeKFVJhSxuQseAYo3/WJB+W44SN96wSeyv1oTrHH/2d6bcob95IfLVmRvToPqzox9TVY16nLMZaSySIqJeUsduirIypf1MS72XqtcT1ji90xi7R2jKQ3E9hx3MvdZ+9G94u9nGLkqrSjmffr07ttsvMOUGJ9Dc5Himo9cbS9j0Nzy9H+j/hba6Fdp6ML9GSJ6wIP02Rb3ZtMXs6BPP3YOnPiGvYvySaz1QDs6bbTCe0idCWOYteBsTMeDEcZzzH+zDzeO61J9XJKbOuARdXeG+rkBLgutVNy/gA9FoZj54xAch3ZbQN1zb0CodBJrXu7suT5TMceHHANCeEMzXKf/+iYYTNG0NXI/gV9/JkSvavNqGtpOPo8whrY7ZJEChgWXm14qOEzrDKf9einNX0IdA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6f8f672d-ccb1-4499-11cc-08d77e603969 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2019 17:33:24.0052 (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: QuOVtpPkbLQZzswv56c+vgQNYit/xNWu4aKwKzRlO0aIy1cbkS28D8t/LpAlE9c/QEqFtqjJUkNwAhOsNUSj9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2448 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-12-11_05:2019-12-11,2019-12-11 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: dev On Behalf Of Ananyev, Konstantin > Sent: Wednesday, December 11, 2019 4:36 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: Re: [dpdk-dev] [PATCH] ethdev: allow multiple security sessions = to use > one rte flow >=20 >=20 > > > > > > > > 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 inbo= und 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 t= o 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 fiel= d to index > into a table (for example), then the above requirement of one rte_flow pe= r 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 ac= tual > lookup. Just that it is not used while creating 'rte_flow'. >=20 > And this table will be prepopulated by user and pointer to it will be som= ehow > 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 explai= n how it's done in OCTEONTX2 PMD. The application would create security_session for every SA. SPI etc would b= e 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. T= his memory is allocated during device configure and h/w would have the poin= ter after the initialization is done. PMD uses SPI as index to write into specific locations(during session creat= e) and h/w would use it when it sees an ESP packet eligible for SECURITY (i= n receive path, per packet). As long as session creation could populate at = memory locations that h/w would look at, this scheme would work. =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 propos= ed > change is to allow more efficient usage of h/w resources where it's permi= tted 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 sessi= on. > > > > + * > > > > + * 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 structur= e. > > > > */ > > > > -- > > > > 2.7.4