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 9464BA04F9; Wed, 18 Dec 2019 14:52:30 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9CF311C01; Wed, 18 Dec 2019 14:52:29 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id DD0D21F5 for ; Wed, 18 Dec 2019 14:52:26 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2019 05:52:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,329,1571727600"; d="scan'208";a="210093801" Received: from vmedvedk-mobl.ger.corp.intel.com (HELO [10.237.220.96]) ([10.237.220.96]) by orsmga008.jf.intel.com with ESMTP; 18 Dec 2019 05:52:22 -0800 To: Anoob Joseph , "Ananyev, Konstantin" , Akhil Goyal , Adrien Mazarguil , "Doherty, Declan" , "Yigit, Ferruh" , Jerin Jacob Kollanukkaran , Thomas Monjalon Cc: Ankur Dwivedi , Hemant Agrawal , Matan Azrad , "Nicolau, Radu" , Shahaf Shuler , Narayana Prasad Raju Athreya , "dev@dpdk.org" References: <1575801683-27269-1-git-send-email-anoobj@marvell.com> <1fc05516-3686-4267-a760-edbe0b92bc87@intel.com> <0a7d957d-e1f6-835b-15d8-4bccc491b4f9@intel.com> <8d5062b2-d7a7-9788-5788-01720dbad2f5@intel.com> From: "Medvedkin, Vladimir" Message-ID: Date: Wed, 18 Dec 2019 13:52:22 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [dpdk-dev] [EXT] Re: [PATCH] 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, On 18/12/2019 03:54, Anoob Joseph wrote: > Hi Vladimir, > > Please see inline. > > Thanks, > Anoob > >> -----Original Message----- >> From: Medvedkin, Vladimir >> Sent: Tuesday, December 17, 2019 11:14 PM >> To: Anoob Joseph ; Ananyev, Konstantin >> ; Akhil Goyal ; >> Adrien Mazarguil ; Doherty, Declan >> ; Yigit, Ferruh ; Jerin >> Jacob Kollanukkaran ; Thomas Monjalon >> >> Cc: Ankur Dwivedi ; Hemant Agrawal >> ; Matan Azrad ; >> Nicolau, Radu ; Shahaf Shuler >> ; Narayana Prasad Raju Athreya >> ; dev@dpdk.org >> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH] ethdev: allow multiple security >> sessions to use one rte flow >> >> Hi Anoob, >> >> On 17/12/2019 14:24, Anoob Joseph wrote: >>> Hi Vladimir, >>> >>> Please see inline. >>> >>> Thanks, >>> Anoob >>> >>>> -----Original Message----- >>>> From: Medvedkin, Vladimir >>>> Sent: Tuesday, December 17, 2019 4:51 PM >>>> To: Anoob Joseph ; Ananyev, Konstantin >>>> ; Akhil Goyal ; >>>> Adrien Mazarguil ; Doherty, Declan >>>> ; Yigit, Ferruh ; >>>> Jerin Jacob Kollanukkaran ; Thomas Monjalon >>>> >>>> Cc: Ankur Dwivedi ; Hemant Agrawal >>>> ; Matan Azrad ; >> Nicolau, >>>> Radu ; Shahaf Shuler >> ; >>>> Narayana Prasad Raju Athreya ; dev@dpdk.org >>>> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH] ethdev: allow multiple >>>> security sessions to use one rte flow >>>> >>>> Hi Anoob, >>>> >>>> On 16/12/2019 16:16, Anoob Joseph wrote: >>>>> Hi Vladimir, >>>>> >>>>> Please see inline. >>>>> >>>>> Thanks, >>>>> Anoob >>>>> >>>>>> -----Original Message----- >>>>>> From: Medvedkin, Vladimir >>>>>> Sent: Monday, December 16, 2019 9:29 PM >>>>>> To: Anoob Joseph ; Ananyev, Konstantin >>>>>> ; Akhil Goyal ; >>>>>> Adrien Mazarguil ; Doherty, Declan >>>>>> ; Yigit, Ferruh ; >>>>>> Jerin Jacob Kollanukkaran ; Thomas Monjalon >>>>>> >>>>>> Cc: Ankur Dwivedi ; Hemant Agrawal >>>>>> ; Matan Azrad ; >>>> Nicolau, >>>>>> Radu ; Shahaf Shuler >>>>>> ; Narayana Prasad Raju Athreya >>>>>> ; dev@dpdk.org >>>>>> Subject: [EXT] Re: [dpdk-dev] [PATCH] ethdev: allow multiple >>>>>> security sessions to use one rte flow >>>>>> >>>>>> External Email >>>>>> >>>>>> ------------------------------------------------------------------- >>>>>> -- >>>>>> - >>>>>> Hi Anoob, >>>>>> >>>>>> On 11/12/2019 17:33, Anoob Joseph wrote: >>>>>>> Hi Konstantin, >>>>>>> >>>>>>> Please see inline. >>>>>>> >>>>>>> Thanks, >>>>>>> Anoob >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: dev On Behalf Of Ananyev, >> Konstantin >>>>>>>> Sent: Wednesday, December 11, 2019 4:36 PM >>>>>>>> To: Anoob Joseph ; Akhil Goyal >>>>>>>> ; Adrien Mazarguil >>>>>>>> ; Doherty, Declan >>>>>>>> ; Yigit, Ferruh >>>>>>>> ; Jerin Jacob Kollanukkaran >>>>>>>> ; Thomas Monjalon >>>>>>>> Cc: Ankur Dwivedi ; Hemant Agrawal >>>>>>>> ; Matan Azrad >> ; >>>>>> Nicolau, >>>>>>>> Radu ; Shahaf Shuler >>>>>>>> ; Narayana Prasad Raju Athreya >>>>>>>> ; dev@dpdk.org >>>>>>>> Subject: Re: [dpdk-dev] [PATCH] 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. >>>>>>>>>> Wonder what will be the usage model for it? >>>>>>>>>> AFAIK, RFC 4301 clearly states that either SPI value alone or >>>>>>>>>> in conjunction with dst (and src) IP should clearly identify SA >>>>>>>>>> for inbound SAD >>>>>>>> lookup. >>>>>>>>>> Am I missing something obvious here? >>>>>>>>> [Anoob] Existing SECURITY action type requires application to >>>>>>>>> create an 'rte_flow' per SA, which is not really required if h/w >>>>>>>>> can use SPI to uniquely >>>>>>>> identify the security session/SA. >>>>>>>>> Existing rte_flow usage: IP (dst,src) + ESP + SPI -> security >>>>>>>>> processing enabled on one security session (ie on SA) >>>>>>>>> >>>>>>>>> The above rule would uniquely identify packets for an SA. But >>>>>>>>> with the above usage, we would quickly exhaust entries available >>>>>>>>> in h/w lookup tables (which are limited on our hardware). But if >>>>>>>>> h/w can use SPI field to index >>>>>>>> into a table (for example), then the above requirement of one >>>>>>>> rte_flow per SA is not required. >>>>>>>>> Proposed rte_flow usage: IP (any) + ESP + SPI (any) -> security >>>>>>>>> processing enabled on all ESP packets >>>>>> So this means that SA will be indexed only by spi? What about SA's >>>>>> which are indexed by SPI+DIP+SIP? >>>>>>>>> Now h/w could use SPI to index into a pre-populated table to get >>>>>>>>> security session. Please do note that, SPI is not ignored during >>>>>>>>> the actual >>>>>>>> lookup. Just that it is not used while creating 'rte_flow'. >>>>>>>> >>>>>>>> And this table will be prepopulated by user and pointer to it >>>>>>>> will be somehow passed via rte_flow API? >>>>>>>> If yes, then what would be the mechanism? >>>>>>> [Anoob] I'm not sure what exactly you meant by user. But may be >>>>>>> I'll explain >>>>>> how it's done in OCTEONTX2 PMD. >>>>>>> The application would create security_session for every SA. SPI >>>>>>> etc would be >>>>>> available to PMD (in conf) when the session is created. Now the PMD >>>>>> would populate SA related params in a specific location that h/w >>>>>> would access. This memory is allocated during device configure and >>>>>> h/w would have the pointer after the initialization is done. >>>>>> If memory is allocated during device configure what is upper limit >>>>>> for number of sessions? What if app needs more? >>>>>>> PMD uses SPI as index to write into specific locations(during >>>>>>> session create) >>>>>> and h/w would use it when it sees an ESP packet eligible for >>>>>> SECURITY (in receive path, per packet). As long as session creation >>>>>> could populate at memory locations that h/w would look at, this >>>>>> scheme would >>>> work. >>>>> [Anoob] Yes. But we need to allow application to control the h/w >>>>> ipsec >>>> processing as well. Let's say, application wants to handle a specific >>>> SPI range in lookaside mode (may be because of unsupported >>>> capabilities?), in that case having rte_flow will help in fine tuning how the >> h/w packet steering happens. >>>> Also, rte_flow enables H/w parsing on incoming packets. This info is >>>> useful even after IPsec processing is complete. Or if application >>>> wants to give higher priority to a range of SPIs, rte_flow would allow doing >> so. >>>>>> What algorithm of indexing by SPI is there? Could I use any >>>>>> arbitrary SPI? If some kind of hashing is used, what about collisions? >>>>> [Anoob] That is implementation dependent. In our PMD, we map it one >> to one. >>>> As in, SPI is used as index in the table. >>>> So, as far as you are mapping one to one and using SPI as an index, a >>>> lot of memory is wasted in the table for unused SPI's.  Also, you are >>>> not able to have a table with 2^32 sessions. It is likely that some >>>> number of SPI's least significant bits are used as an index. And it >>>> raises a question - what if application needs two sessions with different >> SPI's which have the same lsb's? >>> [Anoob] rte_security_session_create() would fail. Why do you say we >> cannot support 2^32 sessions? If it's memory limitation, the same memory >> limitation would apply even if you have dynamic allocation of memory for >> sessions. So at some point session creation would start failing. In our PMD, >> we allow user to specify the range it requires using devargs. >>> Also, collision of LSBs can be avoided by introducing a "MARK" rule in >> addition to "SECURITY" for the rte_flow created for inline ipsec. Currently >> that model is not supported (in the library), but that is one solution to the >> collisions that can be pursued later. >>>> Moreover, what about >>>> two sessions with same SPI but different dst and src ip addresses? >>> [Anoob] Currently our PMD only support UCAST IPSEC. So another session >> with same SPI would result in session creation failure. >> >> Aha, I see, thanks for the explanation. So my suggestion here would be: >> >> - Application defines that some subset of SA's would be inline protocol >> processed. And this SA's will be indexed by SPI only. >> >> - App defines special range for SPI values of this SA's (size of this range is >> defined using devargs) and first SPI value (from configuration?). >> >> - App installs rte_flow only for this range (from first SPI to first SPI >> + range size), not for all SPI values. > [Anoob] This is exactly what this patch proposes. Allowing the SPI and the IP addresses to be range and have security_session provided as NULL. What you have described would be achievable only if we can allow this modification in the lib. > > So can I assume you are in agreement with this patch? Not exactly. I meant it is better to make more specified flow like: ... struct rte_flow_item_esp esp_spec = {         .hdr = {                 .spi = rte_cpu_to_be_32(first_spi),         }, }; struct rte_flow_item_esp esp_mask = {         .hdr = {                 .spi = rte_cpu_to_be_32(nb_ipsec_in_sa - 1),         }, }; pattern[0].type = RTE_FLOW_ITEM_TYPE_ESP; pattern[0].spec = & esp_spec; pattern[0].mask = &esp_mask; ... So this means inline proto device would process only special subset of SPI's. All other will be processed as usual. Sure, you can assign all 2^32 SPI range and it work as you intended earlier. I think we need to have finer grained control here. > >> - Other SPI values would be processed non inline. >> >> In this case we would be able to have SA addressed by longer tuple (i.e. >> SPI+DIP+SIP) outside of before mentioned range, as well as SA with >> unsupported capabilities by inline protocol device. >> >>>>>>>>> The usage of one 'rte_flow' for multiple SAs is not mandatory. It >>>>>>>>> is only required when application requires large number of SAs. >>>>>>>>> The proposed >>>>>>>> change is to allow more efficient usage of h/w resources where it's >>>>>>>> permitted by the PMD. >>>>>>>>>>> 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 452d359..21fa7ed 100644 >>>>>>>>>>> --- a/lib/librte_ethdev/rte_flow.h >>>>>>>>>>> +++ b/lib/librte_ethdev/rte_flow.h >>>>>>>>>>> @@ -2239,6 +2239,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 >>>>>> -- >>>>>> Regards, >>>>>> Vladimir >>>> -- >>>> Regards, >>>> Vladimir >> -- >> Regards, >> Vladimir -- Regards, Vladimir