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 20430A0471 for ; Fri, 16 Aug 2019 10:32:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CEDCF37B7; Fri, 16 Aug 2019 10:32:09 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140050.outbound.protection.outlook.com [40.107.14.50]) by dpdk.org (Postfix) with ESMTP id 24277378B for ; Fri, 16 Aug 2019 10:32:08 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=imDxi9JNUkbNRfr7UhiYff1CbKoo4OqnIKrQbrLV0MuZl6wzkbFPnAY8mM0gEQ8XPDfJo+0DyHhCpsUfawWcjqktJne+cXnGeJv+ywRCAbmC+oud9Lik/U0UkJzAgCHRkgW//Jw5P2SF6raSYK1QY2k0/DgP/cjvrEfS2nUrmR98od7X5luR8dMu4TOmkmCJSuoy6b6d91+0lMEaUS9PvXd0sSVUX5bsz4IPtMN2W/PqR/ToKhBTtSJthlKVJzunR6vCgI6HG1BtDtEnRTnwkVPUaGC34Txc93YfpG1+bjdK5Dd/tUSq0qpFWYTydyUgxxZWvl0zxy09fNmTlazL6Q== 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=RnIn6qL5h3iUgkIvFhh0/eaF7wUTGcTQ+9wYHI5mHek=; b=O9SFN5OeAFyxm3foHeW1M09gbv8bYMp3IsqQsLQlH042iwnlYkHRo1e6zOLwjyJZOJzqvAxbRUukiDNcuz2l3Wwst/W2muUITmHFyzz0giiNQNHyxfLf/QcuitUAAA567goy2itAQ08pJG+bPVjNy6K7tr5NRxV8WRHbXz1qwInAReTpp8hgAEvov7NeY8NOB6nCEINyxLwtKC/28jWrEwCW7OIcsTgKCxNyKSTUVIEBGJ+LmJsJGnTDDw0sUNH0IIpyzdnJxaqkpQ15+McVpmtQ0ZhfttB8pFyosPPotyA5h5zjUZ3BqvBNUdeW/a2e/ixOThGcweYjnqQ4B41MzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RnIn6qL5h3iUgkIvFhh0/eaF7wUTGcTQ+9wYHI5mHek=; b=hkz5UjP8jpQXaXCg0uSJKoZFb8dQgQ8BT1GQ+Q29S5IvK679sZU8LXupiDG2qCnd+7CGwQxu+4PTrb0xHhq1CaLcjL+28wAN3UTj30p94oXaalwqcEZumCq8EUvvEuSj42U3tjHKjnC+Rev33jBLc4fs7mvomN6KeFArNXTDBvk= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (20.179.235.82) by VE1PR04MB6461.eurprd04.prod.outlook.com (20.179.233.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.18; Fri, 16 Aug 2019 08:32:06 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::964:4ddc:346b:e2ec]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::964:4ddc:346b:e2ec%7]) with mapi id 15.20.2157.022; Fri, 16 Aug 2019 08:32:06 +0000 From: Akhil Goyal 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" Thread-Topic: [RFC] ethdev: allow multiple security sessions to use one rte flow Thread-Index: AQHVQiqiQXkSuDRH0UWTk2TJNfxPTqbnY7gAgBMbf4CAABnksIABTd4AgAGUeFA= Date: Fri, 16 Aug 2019 08:32:06 +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: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d528c5c9-5202-4c6b-23a8-08d7222438f1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:VE1PR04MB6461; x-ms-traffictypediagnostic: VE1PR04MB6461: 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)(376002)(396003)(39850400004)(136003)(346002)(366004)(199004)(189003)(15650500001)(8936002)(52536014)(81156014)(6246003)(66066001)(7416002)(478600001)(6116002)(4326008)(53936002)(76176011)(25786009)(6506007)(26005)(86362001)(8676002)(102836004)(3846002)(7696005)(44832011)(81166006)(476003)(186003)(2906002)(486006)(33656002)(55016002)(6436002)(14444005)(305945005)(74316002)(99286004)(71200400001)(66476007)(5660300002)(7736002)(64756008)(446003)(11346002)(256004)(66446008)(66556008)(561944003)(9686003)(54906003)(71190400001)(229853002)(66946007)(76116006)(110136005)(316002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6461; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wTQbVC+zCbc7GB8HBMWPVNVv2xxeaC5fSmy0biz4jNHS5ZVnzDMPBJBaTN11zGpHyWMzZJNeBjvJ+N7nFDTj8mFOAtnZxm9R/4B4twx81Qmu3ivLFIU6MJA59LJWa+vabZHy+1yROfe4JxDfuSGXItq7G+4yNM9/B0YkCwXI7/52lDDl6kV2QnX9+XRuKudSpKJSTVPjxiI+/obXzeYwCXaEu+FjLtorbpwVTD3Q2n7Wf6iw42SP8DuG4zOnwXtwLdGGwnFbkkhGf+AMCWhMwTB8YvRDvK0BPAUuhIKFy8a1iLgxY+sHqkiOLab2vZRBmbIj9pg9JcmgGKYYkhFKYfsMAvmDhHIAbvPvtzhSJ3Nrqx8vgbHNeO8rVEI8htuCt9OX6JuaQK2/kubHUayMCWA+JKYbKQPGBtfDICAGdcw= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: d528c5c9-5202-4c6b-23a8-08d7222438f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2019 08:32:06.4659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YdI95sSfIYOCzphdZtet2xf6W5nWhBnaL++w5vVbT1FonGyKjrm8WfT9id+waazXXpb5qvmLsXNvFqVXMwmSog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6461 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 Anoob, >=20 > Hi Akhil, >=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. > > > > SPI values are normally used to uniquely identify the SA that need to b= e > > 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. Multipl= e plain > > packet flows can use the same session/SA. > > > > Why do you feel that security session provided should be NULL to suppor= t > > multiple flows. > > How will the keys and other SA related info will be passed to the drive= r/HW. >=20 > [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_securit= y > session. 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 informat= ion, 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 r= te_flow > would require to be created. I am not able to understand the issue here. Flow are validated based on som= e pattern, You can identify the flow based on some parameter(currently it is spi in ca= se of inline crypto and also your case). You can perform some action based on the security session that you have cre= ated before validating the flow=20 And that session creation is nowhere linked to the type of flow. You can us= e the same session for as many flows you want. >=20 > In the present model, a security session is created, and then rte_flow wi= ll > connect ESP packets with one SPI to one security session. Instead, when w= e > 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 i= n some > range gets inline processed with the security session identified with its= SPI. >=20 > Our PMD supports limited number of flow entries but our h/w can do SA loo= kup > 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 can be = supported. Ok now I got it. You want to configure a single flow with multiple sessions= 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 time with varied values of SPI= and tunnel IPs. How can One put a range to that. I would rather say, you actually do not need the rte_flows to be configured= for=20 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 the basis of = SPI value which It has stored in the DB and do all the processing. What are the changes that you need in the ipsec-secgw for inline proto to w= ork, there is No flow processing currently in the inline proto case. Will it not work as = is for you?=20 Atleast for NXP devices we are able to work as is without any issue. >=20 > > > > > > > > > > > > Application should do an rte_flow_validate() to make sure the flo= w > > > > > 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 ses= sion. > > > > > + * > > > > > + * 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 item= s > > > > > + 'IPv4' and > > > > > + * 'IPv6' will be allowed to be a range. The rule thus created > > > > > + can enable > > > > > + * SECURITY processing on multiple flows. What you intent here is " The rule thus created can enable multiple securit= y sessions on a single rte flow" Regards, Akhil