From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4BBFFC3A59C for ; Fri, 16 Aug 2019 10:13:01 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 93D91206C1 for ; Fri, 16 Aug 2019 10:13:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=marvell.com header.i=@marvell.com header.b="Hhr1nEvz"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=marvell.onmicrosoft.com header.i=@marvell.onmicrosoft.com header.b="A1+4zPS7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 93D91206C1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=marvell.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 75B341BF01; Fri, 16 Aug 2019 12:12:59 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 365791BED1 for ; Fri, 16 Aug 2019 12:12:58 +0200 (CEST) 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 x7GAABfj021177; Fri, 16 Aug 2019 03:12:57 -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=8LGlGb3L0shOOpKLYR8NDgZ9bvnbrUkF6RgZ2jFdK7s=; b=Hhr1nEvz3YLf58O7Ey26Qd5/x7hU5hMFtO0vDfbkdRnhY1wggNkfWFGMZ4RSt5L5oPdq 3DTZAo7TU2dLpbLG+iMwRRZTCOFGlamiueG+J1phnQ9s79ETatnDzCGw+j78wCsIDpoE nRF74+0jcIm6Mhsf0qEFyPMpVb/NbcDX1pO9wNqOVPMrXI/q7jlgq7tCtW1Dhkhcmsle RVGAaky3BRNg46UxS4zjhDavwYW7w9CqJCGHQEoxV7dskkCdO/hA4IHefeehC0Lsmbhk HoSdYma5BbeJYWCP9qCqdlJ+eFOY84cudC7wEeZZAbfndoE2W2TLdkn0cDzj0oocVoh7 Aw== Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0b-0016f401.pphosted.com with ESMTP id 2udefw29ha-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 16 Aug 2019 03:12:56 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 16 Aug 2019 03:12:54 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (104.47.34.55) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Fri, 16 Aug 2019 03:12:54 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fd1TuX11e+PNzp4DP3YVi8sXlIcgXOFDJBfzRS7bjOBbV0ATc6i3zy8cqv8ZBnYUyC07LzEAO7JKXtgT8de77XtpkKTVJ7VbiDLREsNpUdp+QymoFbkRZfxq775PfK6UjcL9qFaNkI7L+3xvDSdusRmSnUeJNj6VTaD+JAA7adb3AtH+8bLU8j3zh4JRAkRjLpc2a+ba8hNR1NOoGIMK/bGYPtFMX8cZjySxNy9BAGp1P4iNlKoXINseGOZGKAeaBGZjI9RTkbHuEC3w0xwL67l3Z9Efvv5DE7eaon5rag5gVIZGp6BY2HUD0uI5JCGq/aS1xL85gf/4L1veHFdEdg== 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=8LGlGb3L0shOOpKLYR8NDgZ9bvnbrUkF6RgZ2jFdK7s=; b=fgESbuMTt+x69LrsgePkqwxsjoX4HpMhYHy1+/1EqrbdRLVTaJ3TH4NT5rFQA+PY8278o2iRefkG+Kh54UE9JBraVf18fm2gr/TNKf+IW2UQkA+Y+j+hJLsI3xDQCgfwxmCv+dPwu3VgDPAoNaZGmTzWxwif0x0pFpDLDN4PMcklWkFVhGXrh/KkHvdmyUoY4Mia7hLVyyayKs5kHAZNkIGsZrkHAfcj7qWQRgUCgEBRxVyn0g7t9SxYjK4wfrOoqTOOcpzfSIT3a9wizGLz+e/4YJlZ97xlDGfxuwEwtxqc2ehtfZ9Xmn1c2QPwfAYu6WPdcpZ+AKMWH0OaENegYA== 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=8LGlGb3L0shOOpKLYR8NDgZ9bvnbrUkF6RgZ2jFdK7s=; b=A1+4zPS7GgDV7UUT7dRQhMMuS4uoiJBY7YLBY0Wg8hEfAqPlRBOWvkwGNTfM7oPN7ORlC/GWeQZb8wuyfyrExZ5aY7H5gKFCgAi9gmM+bqYuq6Id6vmI1XV59WJVxXuBsgNcKs0QOtEYLp4Kb50GXVew0gx3nrs5F3JeTXrO6ug= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB3005.namprd18.prod.outlook.com (20.179.82.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.14; Fri, 16 Aug 2019 10:12:53 +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; Fri, 16 Aug 2019 10:12:53 +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+Q3LzHQ2jE6n11KGx7fifKbnYxIAgBMawVCAAB63AIAAAysQgAL2IgCAAArlAA== Date: Fri, 16 Aug 2019 10:12:53 +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: [115.113.156.2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 59c2e153-6063-456d-11bb-08d722324d3f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR18MB3005; x-ms-traffictypediagnostic: MN2PR18MB3005: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0131D22242 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39840400004)(376002)(366004)(346002)(199004)(13464003)(189003)(52536014)(33656002)(53546011)(561944003)(55236004)(26005)(8676002)(2906002)(76176011)(99286004)(7696005)(74316002)(316002)(4326008)(7736002)(25786009)(86362001)(305945005)(7416002)(66946007)(76116006)(256004)(14444005)(14454004)(446003)(53936002)(110136005)(54906003)(55016002)(486006)(9686003)(6436002)(6246003)(478600001)(229853002)(15650500001)(71190400001)(71200400001)(66476007)(476003)(102836004)(8936002)(81156014)(3846002)(5660300002)(186003)(66066001)(66556008)(6116002)(6506007)(11346002)(64756008)(81166006)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB3005; 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-message-info: 0zxdQ9aSg3AB1qZzzK1z0auVh8hhB1sBUtAY6S7pQLUBs4H4E0a1GZR3ekbBoUMWba8nWBPO9YxrpSzXNvasYMG/Lgy5CESj+q6LASkoAfIORySEUzH0S5Gzvfs4fCrWm2/TaJ3OVl/GWr1C5mnPhOHrTi7+CCBe/N7hiXf4B1Lqs8tFI051gagIdBPbg8sIRZLISOq3Ww4mauKpwKygF4iMAiLa+WVE6WwYmrUcfZUDr6yaYGHPVbApYx+zUHSfqtkmxcSQCTQiIl7SUhkOVQR7/f9uNbtWYV4LVsSkYMOeojCJlt8bPt7Xloy77Yj2EBA1ZsD15Te0hkqJC5x4LKmLaNRqgM9MXsQShRNUW1qD/Iog2rBESKr1HZfBKG2s29l/WHd1cq9Neb2lFjVFDgAxi4pGpxz1umXGI3vwS8U= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 59c2e153-6063-456d-11bb-08d722324d3f X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2019 10:12:53.4323 (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: XXkk0Hd4WZmHBzEyS6P/34RMzw/+tPY8BNVv+eFUCtQb3P1rfb8sj8HTt0M/+KGAjG6YFivz2auWkn3r70VKhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3005 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-16_05:2019-08-16,2019-08-16 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: dev On Behalf Of Akhil Goyal > Sent: Friday, August 16, 2019 2:02 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: [dpdk-dev] [RFC] ethdev: allow multiple security sessions to= use > one rte flow >=20 > Hi Anoob, > > > > Hi Akhil, > > > > > > > > > > > > > > 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. > > > > > > 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. > > > > > > Plain packet IP addresses can be a range. That is not an issue. > > > Multiple plain packet flows can use the same session/SA. > > > > > > 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 proposal here only changes the 1:1 dependency of rte_flow and > > rte_security session. >=20 > I don't see this dependency for rte_flow and security session. > Multiple flows can be configured to use the same security session. >=20 > > > > The h/w could use SPI field in the received packet to identify SA(ie, > > rte_security session). If the h/w allows to index into a table which > > holds SA information, 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. >=20 > I am not able to understand the issue here. Flow are validated based on > some pattern, You can identify the flow based on some parameter(currently > it is spi in case of inline crypto and also your case). > You can perform some action based on the security session that you have > created before validating the flow And that session creation is nowhere > linked to the type of flow. You can use the same session for as many flow= s > you want. >=20 > > > > 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 be accessed during data path handling. And the > > rte_flow could say, all SPI in some range gets inline processed with th= e > security session identified with its SPI. > > > > Our PMD supports limited number of flow entries but our h/w can do SA > > lookup without flow entries(using SPI instead). So the current > > approach of one flow per session is creating an artificial limit to the= number > of SAs that can be supported. >=20 > Ok now I got it. You want to configure a single flow with multiple sessio= ns in > it. > But defining a range in SPI and tunnel IP addresses does not make sense. = In > real world applications, Sessions can be created and destroyed at any tim= e > with varied values of SPI and tunnel IPs. How can One put a range to that= . >=20 > I would rather say, you actually do not need the rte_flows to be configur= ed > for Inline protocol processing. You have configured all the session info = in the > hw while Creating the session and your H/W will be able to identify on th= e > basis of SPI value which It has stored in the DB and do all the processin= g. [Anoob] Yes. That is the model being followed right now. Concern is, whethe= r this would be deviating from the spec. In other words, we could have devi= ces which would need rte_flow for every rte_security session (ixgbe needs f= or inline crypto), and then we could have devices which doesn't need per se= ssion rte_flow (which is our case). What do you think is the right approach= for supporting both kinds of devices? > =20 > What are the changes that you need in the ipsec-secgw for inline proto to > work, there is No flow processing currently in the inline proto case. Wil= l it not > work as is for you? [Anoob] In ipsec-secgw, a default flow would be created per security enable= d port with 'conf=3DNULL' & SPI =3D 'ANY'. Flow validate would be done to m= ake sure the underlying PMD supports it. For PMDs which doesn't support thi= s model, per SA flow would be created. =20 > Atleast for NXP devices we are able to work as is without any issue. [Anoob] Just curious, would having such a dependency on rte_flow be an issu= e for NXP devices? =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 > 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. >=20 > What you intent here is " The rule thus created can enable multiple secur= ity > sessions on a single rte flow" >=20 >=20 > Regards, > Akhil