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 2F99CA0471 for ; Thu, 15 Aug 2019 11:48:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 557711BE92; Thu, 15 Aug 2019 11:48:33 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 046D71BE8F for ; Thu, 15 Aug 2019 11:48:31 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2019 02:48:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,388,1559545200"; d="scan'208";a="176830319" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga008.fm.intel.com with ESMTP; 15 Aug 2019 02:48:28 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.73]) by IRSMSX154.ger.corp.intel.com ([169.254.12.14]) with mapi id 14.03.0439.000; Thu, 15 Aug 2019 10:48:27 +0100 From: "Ananyev, Konstantin" 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" Thread-Topic: [RFC] ethdev: allow multiple security sessions to use one rte flow Thread-Index: AQHVQiqgDO3Htc38yE2z7GH/gg5FZqbnUvQAgBMbf4CAAB1TAIABSm8AgABB15A= Date: Thu, 15 Aug 2019 09:48:26 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258018115F7E3@irsmsx105.ger.corp.intel.com> References: <1563977848-30101-1-git-send-email-anoobj@marvell.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODVkMTcwMWYtOTQyYi00ZGFlLWE2YzMtNjQ3MjQzODY4MTNkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoia2tXZytrcjA2cXgybk04MDhcLzVGU3o1cldpcHY1RFdtQVIrbzNkcUFEbXdNajlDN09veStVblRsK2pSOCtcL2dMIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.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 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 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_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 ou= r 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 > 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 we create the security session, h/w can populate entries in a DB tha= t would be accessed during data path handling. And the rte_flow > could say, all SPI in 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 flow per session is creating an artificial limit to the n= umber of SAs that can be supported. QQ: Would that change be accompanied with real implementation for some part= icular PMD? Konstantin >=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. > > > > > + * > > > > > */ > > > > > struct rte_flow_action_security { > > > > > void *security_session; /**< Pointer to security session struct= ure. > > > > > */ > > > > > -- > > > > > 2.7.4