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 EC281A0471 for ; Fri, 16 Aug 2019 05:24:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DEEB71BEF8; Fri, 16 Aug 2019 05:24:34 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id E82E71BEA2 for ; Fri, 16 Aug 2019 05:24:32 +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 x7G3OV8j013446; Thu, 15 Aug 2019 20:24:31 -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=J7zhPvoEQ7DysSGL12q+hKbjEeZ28baTbl19DG/lwXo=; b=YaM0SqvMgnaNi4L7TlmJO/wQZbvyD64hk5rKYvo95q0dR6ekaM+AwvBNBIHDacUMW4p2 5NsQGDxAk3S1t0LJlJAk+lMTEFJoBsXLVoJMaiT7CltsEylMBdkOdCCjcD/LE7khH39y tLYGWWYNvtsEc/0pBalDxM2vFVcqJPRQr5ljKJkEuNvbM4l94TlTlQlyU6DtNRc9XPMp dLq0ed2TSunnELHUa6NC6z4KSRslB4Qngg8eMlOxiIgwypTDInJjf6wdIjyjYaKeeZ9E sBpW2tadLqo0iCjfOSEZ8pdHK/3LIH5NEpBWRf71nJQfIVxRNkq8yjFD9ZeE1tXTAWmO kg== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0b-0016f401.pphosted.com with ESMTP id 2udefw15w6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 20:24:31 -0700 Received: from SC-EXCH01.marvell.com (10.93.176.81) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 15 Aug 2019 20:24:29 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (104.47.40.59) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Thu, 15 Aug 2019 20:24:29 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gbfkxuST0NmI4UiyQ1e7zx05jGYxK0+Hq17xDYLrUCUxg25hNzIpQbCvqTo/hPk/QuFO5NxcVIQQKdYNlgL6JLIRjqSIzP1QNaVO31F53f8Mcu6Bfd0XzyZT09+2jluhyb3j7m4BTqD+BnVgXdmG8LL2EtD9n2epmPQXrOQd0jhXY2qPmzUeD29MLQzHwxTO7IRziClhJ07RRR+zS/9ubeL0Q/WGl7ZD9iR/zzuVbIOuW0SHzhySWGHgN7IBUWdjgNl8x5UbhAOGIKVRDjIdE6eHV7jPJLmga1yS3w42uJd52Ra7hlo+a64yyi7qdRaSUjIbPOJbrqfYAU7VjQEPHA== 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=J7zhPvoEQ7DysSGL12q+hKbjEeZ28baTbl19DG/lwXo=; b=O+hyIlz7A0hKxlI/UZ091gzTX+IXgeqyDNYF8LVMykTb3KjLHHQTxZq9DXH8+WCTy7vKxZx/CxAAr/PBj2jsVB3gHczTXj2B4eF3k9gB9SoFQ6ohjMkJ/PiQlH9Hh1QR4ZyPkxntRqFIBNIyODebKRzOAIoVwFPJLLSpisfpOLP5x07v9wCQSMQE/gbihWloiv0ph83RFkXmkNs0tKJQYkXTckEdbqtYrIRdAM8bxdFRqjEauq2sEBwFbR10Bx++VjjdBVPTemnU3DQ+USdTXfqS0MIcnu6r42pf8DeYFHJgCXurSBwaDVoiBbkUQiTHlBRAHNjTJEPIVVamNULZvA== 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=J7zhPvoEQ7DysSGL12q+hKbjEeZ28baTbl19DG/lwXo=; b=CB0BurfcSkdIJCViGCx30SJGYoaHI7BPuizau966Ce3O2TWjfbQgLUBwBFMP4ZV5vXGgfiiDTS53xbkNeSFGD0T3cuULhhZ5pAGM8d0Zzj+2O6u+HROF0Nm8DQqPCvID49WYY6pHsrNyZxKOxUn8aHXKA6ldKn8Zd1lZWGFY14w= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB2879.namprd18.prod.outlook.com (20.179.22.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.20; Fri, 16 Aug 2019 03:24:25 +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 03:24:25 +0000 From: Anoob Joseph To: "Ananyev, Konstantin" , Akhil Goyal , Adrien Mazarguil , "Doherty, Declan" , "De Lara Guarch, Pablo" , Thomas Monjalon CC: Jerin Jacob Kollanukkaran , "Narayana Prasad Raju Athreya" , Ankur Dwivedi , "Shahaf Shuler" , Hemant Agrawal , "Matan Azrad" , Yongseok Koh , "Lu, Wenzhuo" , "Nicolau, Radu" , "dev@dpdk.org" Thread-Topic: [RFC] ethdev: allow multiple security sessions to use one rte flow Thread-Index: AQHVQiqb+Q3LzHQ2jE6n11KGx7fifKbnYxIAgBMawVCAAB63AIAAAysQgAF5IQCAASXRkA== Date: Fri, 16 Aug 2019 03:24:25 +0000 Message-ID: References: <1563977848-30101-1-git-send-email-anoobj@marvell.com> <2601191342CEEE43887BDE71AB977258018115F7E3@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258018115F7E3@irsmsx105.ger.corp.intel.com> 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: 0ec51546-f84d-4af4-91f1-08d721f93d3e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR18MB2879; x-ms-traffictypediagnostic: MN2PR18MB2879: 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)(366004)(39860400002)(396003)(136003)(346002)(199004)(13464003)(189003)(7416002)(486006)(561944003)(7696005)(76176011)(26005)(305945005)(7736002)(74316002)(3846002)(53936002)(186003)(6116002)(102836004)(55236004)(53546011)(6506007)(86362001)(81166006)(14444005)(25786009)(15650500001)(110136005)(81156014)(256004)(54906003)(316002)(99286004)(8936002)(33656002)(66066001)(66446008)(8676002)(66946007)(2906002)(4326008)(76116006)(64756008)(66556008)(6246003)(71200400001)(66476007)(14454004)(446003)(478600001)(229853002)(476003)(9686003)(11346002)(55016002)(71190400001)(6436002)(5660300002)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB2879; 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: iCeLFE0SUrIEAoE80yr8+RFaHoP7SHm3KLeGDpXDIQZ7fL6cBjl7o5o1cUFj0htZtuqic+CGMcVRW90/GtmVm5wQ/KbPCjRzu6sFyqxsC7aaUq1R/YweSaNN2oTkTBNk0uwsJJ9jDftYAQkWXoXRnVv1UUGfjr13PYo/A0m1pIRMTep+9expAh4CPwBXuYhTOxxG5+7llbL8mZUwCMVotjPHYnrh9Fn8GkngvZSMfRkRJ7y1O398BpFnxf5iaZD4bdIfQGa66W6scf6kfACUH50u3kRqw5S6ohefBJdiNw3jiZ51XHNFM00N9aAU1pS2ZY2hgre3fhGmfEpUiU3XzaCwidXKMHYl0qr7CAaIAHiOoTZesyUEWydvG7TaOckJFO/ML/OFEj6inHGCuFHS6IoZsfJnAlBJJIYCmjN0z3k= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0ec51546-f84d-4af4-91f1-08d721f93d3e X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2019 03:24:25.3229 (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: zJbMuTe+5fDSJ5rCfpAoEhqOxVaxIZH0eYQo1uv2xbnyPZd5afWyrH55wY1wYKd5Cz/afcX6xjdqQUIiDyfRIA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2879 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-16_02:2019-08-14,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 Konstantin, Please see inline. Thanks, Anoob > -----Original Message----- > From: Ananyev, Konstantin > Sent: Thursday, August 15, 2019 3:18 PM > To: Anoob Joseph ; Akhil Goyal > ; Adrien Mazarguil ; > Doherty, Declan ; De Lara Guarch, Pablo > ; Thomas Monjalon > > Cc: Jerin Jacob Kollanukkaran ; Narayana Prasad Raju > Athreya ; Ankur Dwivedi > ; Shahaf Shuler ; > Hemant Agrawal ; Matan Azrad > ; Yongseok Koh ; Lu, > Wenzhuo ; Nicolau, Radu > ; dev@dpdk.org > Subject: RE: [RFC] ethdev: allow multiple security sessions to use one rt= e > flow >=20 > Hi Anoob, >=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 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. > > > > 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. > > > > 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 cou= ld > say, all SPI in some range gets inline processed with the security sessio= n > 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 > QQ: Would that change be accompanied with real implementation for some > particular PMD? > Konstantin [Anoob] Yes. This will be implemented as part of the rte_security additions= in net_octeontx2 PMD, which will be upstreamed this release cycle. >=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. > > > > > > + * > > > > > > */ > > > > > > struct rte_flow_action_security { > > > > > > void *security_session; /**< Pointer to security session > structure. > > > > > > */ > > > > > > -- > > > > > > 2.7.4