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 518EEA0471 for ; Thu, 15 Aug 2019 08:50:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 18F0D5681; Thu, 15 Aug 2019 08:50:06 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 4C26C271 for ; Thu, 15 Aug 2019 08:50:04 +0200 (CEST) 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 x7F6iwYV014455; Wed, 14 Aug 2019 23:50:02 -0700 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=gMZYCfk4f3js3f6Yy3VqHtfNtk0/vPY8+xIXmfmkb8o=; b=pmDsNOXzIRtcEvDuXtF9KSrDabDI1tpjD+8ZeGkcwLfVUDd2RPzBbM6CoAY9CLyPhh5r eM+YV3tMTkOAYl3o8ROgVVYdLwKgElCE0qYqCK5oocfzh+mBcafO5wLqJWtYUwNv7WQY 2IY2gFfveteNl2qR356oqXrQYnR6fTxdffHrsY+zv9o8p+tknq3V1hxAE35hJ6JGYWlC BTKpt/BzhpB7H43C8JmZ3rDj8vkWvY9j5yDaaQ9wX4oAhyzSmZ+E2eUiYZrxHqGND6Hl c2hgxbnhY6A5UVc+yolLmVw0xZE538FEBUJBZgu4M7kZwJgbncYdd3lUf8vKsHljWEgh 6A== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0a-0016f401.pphosted.com with ESMTP id 2ubfad3ccd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 23:50:02 -0700 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, 14 Aug 2019 23:50:00 -0700 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (104.47.48.55) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 14 Aug 2019 23:50:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SJKVhhcIqwuQQ3Hti+1oucliXSFa5knotdA3y5mm+BNwyOjGGW/gwue1naHPLGV6EFjMsy3AWJ+CnwYZ8HyFloMxi18SFcfOKwYAlAz32LtYX/qk5erIFOJYV5AjQtjqqHe0SRoX8+2U5Whkp8EufXLpvAPE+6il/uNVJSGotc8F7XnnRUY5lDzle7gCqcNO3RVr+DGPAf7H9DAwWXHS2I+wzywh5cqTTJk2JL9MU8XdX6vMTrgosY1UVPZGHw0XoC6es1UeAFfBiYM3U7a1+1TBpVpLhAOji8wKjQVlKhcdZwDZUkA9JzrsLtjBGffrJNEJcrkwb9fSEQAtmV8srg== 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=gMZYCfk4f3js3f6Yy3VqHtfNtk0/vPY8+xIXmfmkb8o=; b=oLTGu7hlH+EA/fI2OrJS0OMmJHX7iWppbd5kmAA2mbz65CbQ9rjmCcC+k4kUcJXqOdwsreR92hS9FfIMtMKeJcC66NyJPOWfxhix9SECDj8OE5Sn6lC9jQgFUFTELE49qP/6yAhTCsMt1s0fA0lwJk+Fs7W8ZQR15NuR/49sibgA7yWkT2aFzbDQwPe2YngTuJI6xTa611sANKQuhdzfaUhpiGtFEVLSx3h+G9sLh3mvOePHHhc7CaNNE87q1y90Y8uw4BgbU4egtc32CveMWTzR0pIhNypcYOn7rFeqdyg21fHClxsaL42aw2NGN7tf5PSKZ3yS/GC2y7jbOh5R2g== 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=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gMZYCfk4f3js3f6Yy3VqHtfNtk0/vPY8+xIXmfmkb8o=; b=UpCf7VumvDsGUfYN0JSUyTFkvzsTancozEGS9f2WW45jrmvsgNhXZByAywqf1ghmyKo/SA3FmskTP2YsH2Ifx0zRYFovIiSUdeaq+4L6VHyYNKGLLGJ2s23sXk8Xivpb20QfxbGXxaDmxLo7HPvWSuN7RI0TcZmjbJ/z4NA18LY= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB3182.namprd18.prod.outlook.com (10.255.236.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.14; Thu, 15 Aug 2019 06:49:58 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::7cdd:71d0:6771:4bed]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::7cdd:71d0:6771:4bed%6]) with mapi id 15.20.2157.022; Thu, 15 Aug 2019 06:49:58 +0000 From: Anoob Joseph To: Akhil Goyal , Adrien Mazarguil , Declan Doherty , Pablo de Lara , Thomas Monjalon CC: Jerin Jacob Kollanukkaran , "Narayana Prasad Raju Athreya" , Ankur Dwivedi , "Shahaf Shuler" , Hemant Agrawal , "Matan Azrad" , Yongseok Koh , Wenzhuo Lu , Konstantin Ananyev , Radu Nicolau , "dev@dpdk.org" Thread-Topic: [RFC] ethdev: allow multiple security sessions to use one rte flow Thread-Index: AQHVQiqb+Q3LzHQ2jE6n11KGx7fifKbnYxIAgBMawVCAAB63AIAAAysQ Date: Thu, 15 Aug 2019 06:49:58 +0000 Message-ID: References: <1563977848-30101-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: [223.230.96.6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aeb4a20a-afee-4a33-0b1a-08d7214cc9e5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR18MB3182; x-ms-traffictypediagnostic: MN2PR18MB3182: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01304918F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39850400004)(346002)(396003)(366004)(136003)(13464003)(189003)(199004)(53754006)(54906003)(110136005)(8936002)(561944003)(66066001)(81156014)(81166006)(33656002)(316002)(55016002)(15650500001)(53936002)(229853002)(9686003)(2906002)(14444005)(4326008)(6436002)(25786009)(486006)(476003)(446003)(11346002)(256004)(6246003)(53546011)(71190400001)(71200400001)(64756008)(6116002)(6506007)(3846002)(86362001)(66946007)(66446008)(66556008)(66476007)(5660300002)(76116006)(26005)(8676002)(186003)(14454004)(102836004)(7736002)(7416002)(305945005)(478600001)(99286004)(74316002)(52536014)(7696005)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB3182; 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-message-info: 4yqO8E+/Gck6AvR9lUik6H9dcdZ5fIdRI8KKkF3A6TQLNTIjCGTMeG1G6lVFvmvYtTIpL1FHvmg1/J8h0950flRhj2x66XY9rFIMIm88FVt+3dxN2/z44itbGzsOP/BfE99sR4QeaiaSNju5TMLyzELr15OtlXpyO070ooiE/4fMWTZV0CVabg/AQgIfQMbJhMqa1CAZlG5ZCpNMtSnYIQDL5W9AGq5tKplxJyaLUUzEnFELh8pLf31gXKzWCtdhy00lX1BB1B7KOEapmlZhAAD9eACAe8Y9pTRFVMZpI8Y0VGKJjn4cw2Og8zFDdmJ0nIUeiGGCS/2YbywWchh9O8rFqDp5sMbkiu6u0hEBFKXERanUCAsYV6GP9p1gnGd8nrDi3feuaL6gxwY7Svc+Ttnm7Q6u9dHD7Teo00Ta6UY= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aeb4a20a-afee-4a33-0b1a-08d7214cc9e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2019 06:49:58.3957 (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: lWvn2n//6UVZpOaGwb2iBdxmG9ZU2HAnbg84H+3KR22ZL3H1B0dYUIBzxE8zdhcSljcfAjIASktNQhOMI4jmtw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3182 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-15_02:2019-08-14,2019-08-15 signatures=0 Subject: Re: [dpdk-dev] [RFC] 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 Akhil, Please see inline. Thanks, Anoob > -----Original Message----- > From: Akhil Goyal > Sent: Wednesday, August 14, 2019 4:37 PM > To: Anoob Joseph ; Adrien Mazarguil > ; Declan Doherty > ; Pablo de Lara > ; Thomas Monjalon > > Cc: Jerin Jacob Kollanukkaran ; Narayana Prasad Raju > Athreya ; Ankur Dwivedi > ; Shahaf Shuler ; > Hemant Agrawal ; Matan Azrad > ; Yongseok Koh ; Wenzhuo > Lu ; Konstantin Ananyev > ; Radu Nicolau ; > dev@dpdk.org > Subject: RE: [RFC] ethdev: allow multiple security sessions to use one rt= e > flow >=20 > Hi Anoob, >=20 > > > > Hi all, > > > > Reminder...! > > > Sorry for a delayed response. >=20 > > If there are no concerns, I'll send the patch after adding the > > required changes in ipsec-secgw as well. > > > > Thanks, > > Anoob > > > > > -----Original Message----- > > > From: Anoob Joseph > > > Sent: Friday, August 2, 2019 11:05 AM > > > To: Anoob Joseph ; Akhil Goyal > > > ; Adrien Mazarguil > > > ; Declan Doherty > > > ; Pablo de Lara > > > ; Thomas Monjalon > > > > > > Cc: Jerin Jacob Kollanukkaran ; Narayana Prasad > > > Raju Athreya ; Ankur Dwivedi > > > ; Shahaf Shuler ; > Hemant > > > Agrawal ; Matan Azrad > ; > > > Yongseok Koh ; Wenzhuo Lu > > > ; Konstantin Ananyev > > > ; Radu Nicolau > > > ; dev@dpdk.org > > > Subject: RE: [RFC] ethdev: allow multiple security sessions to use > > > one rte flow > > > > > > Hi Akhil, Adrien, Declan, Pablo, > > > > > > Can you review this proposal and share your feedback? > > > > > > Thanks, > > > Anoob > > > > > > > -----Original Message----- > > > > From: Anoob Joseph > > > > Sent: Wednesday, July 24, 2019 7:47 PM > > > > To: Akhil Goyal ; Adrien Mazarguil > > > > ; Declan Doherty > > > > ; Pablo de Lara > > > > ; Thomas Monjalon > > > > > > > > Cc: Anoob Joseph ; Jerin Jacob Kollanukkaran > > > > ; Narayana Prasad Raju Athreya > > > > ; Ankur Dwivedi ; > > > Shahaf > > > > Shuler ; Hemant Agrawal > > > > ; Matan Azrad ; > > > Yongseok > > > > Koh ; Wenzhuo Lu ; > > > > Konstantin Ananyev ; Radu Nicolau > > > > ; dev@dpdk.org > > > > Subject: [RFC] ethdev: allow multiple security sessions to use one > > > > rte flow > > > > > > > > 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. >=20 > SPI values are normally used to uniquely identify the SA that need to be > applied on a particular flow. > I believe SPI value should not be a range for applying a particular SA or > session. >=20 > Plain packet IP addresses can be a range. That is not an issue. Multiple = plain > packet flows can use the same session/SA. >=20 > Why do you feel that security session provided should be NULL to support > multiple flows. > How will the keys and other SA related info will be passed to the driver/= HW. [Anoob] The SA configuration would be done via rte_security session. The pr= oposal here only changes the 1:1 dependency of rte_flow and rte_security se= ssion.=20 The h/w could use SPI field in the received packet to identify SA(ie, rte_s= ecurity session). If the h/w allows to index into a table which holds SA in= formation, then per SPI rte_flow is not required. This is in fact our case.= And for PMDs which doesn't do it this way, rte_flow_validate() would fail = and then per SPI rte_flow would require to be created. In the present model, a security session is created, and then rte_flow will= connect ESP packets with one SPI to one security session. Instead, when we= create the security session, h/w can populate entries in a DB that would b= e accessed during data path handling. And the rte_flow could say, all SPI i= n some range gets inline processed with the security session identified wit= h its SPI. Our PMD supports limited number of flow entries but our h/w can do SA looku= p without flow entries(using SPI instead). So the current approach of one f= low per session is creating an artificial limit to the number of SAs that c= an be supported. =20 >=20 > > > > > > > > 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 f3a8fb1..4977d3c 100644 > > > > --- a/lib/librte_ethdev/rte_flow.h > > > > +++ b/lib/librte_ethdev/rte_flow.h > > > > @@ -1879,6 +1879,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