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 00599A2EFC for ; Thu, 19 Sep 2019 09:33:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 50BA01E972; Thu, 19 Sep 2019 09:33:58 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 40D101E969 for ; Thu, 19 Sep 2019 09:33:56 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2019 00:33:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,522,1559545200"; d="scan'208";a="177968764" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga007.jf.intel.com with ESMTP; 19 Sep 2019 00:33:53 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by IRSMSX103.ger.corp.intel.com ([169.254.3.36]) with mapi id 14.03.0439.000; Thu, 19 Sep 2019 08:33:52 +0100 From: "Ananyev, Konstantin" To: Anoob Joseph , "Smoczynski, MarcinX" , "akhil.goyal@nxp.com" CC: "dev@dpdk.org" , Narayana Prasad Raju Athreya , Jerin Jacob Kollanukkaran , Archana Muniganti Thread-Topic: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add fallback session Thread-Index: AQHVbey4eK1ocoT+m02CjRaKZhOAgacxHZ4AgAAhoACAAMB6oIAAPcOAgABaXEA= Date: Thu, 19 Sep 2019 07:33:51 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580191967349@irsmsx105.ger.corp.intel.com> References: <20190814204847.15600-1-marcinx.smoczynski@intel.com> <20190904141642.14820-1-marcinx.smoczynski@intel.com> <2601191342CEEE43887BDE71AB9772580191966C6D@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772580191966FFC@irsmsx105.ger.corp.intel.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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTI5YzFhYjEtYWQzOS00OGNlLWEyOTMtMThjYzgzMzVkODI2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTHJWU1wvXC9BSFhORVliRjdsZDlmNElZdys5YmdlTkFNV0V4dXNCQW9PR0xINml5SWZWRXRzdGFjaHlqaTlGOG9QIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add fallback session 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, > > > > > Sorry for the late response. But how do you plan to handle "inlin= e > > protocol" > > > > processed packets? > > > > > > > > Right now that feature is supported for "inline crypto" only. > > > > > > [Anoob] The description says "inline processed" packets. Hence the co= nfusion. > > > > > > > For the case when SA doesn't enable replay window and/or ESN curren= t > > > > patch should also work for "inline proto" too, but this is just my > > > > understanding (not tested, etc.). > > > > > > [Anoob] In case of inline ipsec processing, the ipsec state (which > > > would track sequence number etc) will be internal to the PMDs. So > > > anti- replay/ESN would have to be done either in the h/w or PMD. This= would > > mean application will not have state information regarding ipsec proces= sing. > > Hence fallback handling with the above scheme will not work in that cas= e. > > > > Agree, that's why I wrote above that current wok might work for inline-= proto > > *only* if replay window and ESN is disabled. >=20 > [Anoob] Any feature that makes use of protocol "state" would fail with th= is scheme. In case of inline ipsec, that is anti-replay & ESN. I see > that you are not planning for fallback session for outbound. If at all th= at is planned, this scheme will fail to co-ordinate sequence number > between original and fallback sessions. Right now we don't do outbound fallback sessions. Again, similar scheme would work for TX with lookaside-none and inline-cryp= to, but not for inline/lookaside-proto. Of course few extra changes would be needed - move fragmentation before ips= ec processing part.=20 >=20 > > > > > > > > To address this properly for inline protocol, we will have to come up > > > with some logic to share session private data b/w "eligible" PMDs. Th= is would > > involve library changes to rte_security, etc. > > > > Again, totally agree. > > As I remember we already discussed it about a year ago, but didn't come= up with > > any concrete proposal. > > > > > Once that is proposed, there will be one kind of handling for inline > > > protocol processing and another kind for inline crypto processing. Wo= uld you > > be fine with that? > > > > For sure something needs to be changed for inline-proto to sync replay- > > window/ESN related data between HW/PMD and SW. > > What it should be - new function, or something else - hard to tell righ= t now. >=20 > [Anoob] No disagreement. My only concern is the incompleteness of this so= lution. > We will have to propose a totally new scheme for inline > protocol. Sure, looking forward for it. In fact, I asked these questions a year ago but as I said before there was = no progress on that. > You do agree that this approach will not help inline protocol offloading,= right? Yes, see above. > If you are okay with having different solutions for > inline crypto & inline protocol, I don't have any issue with this series. >=20 > Also, how do you plan to pass "state" info to lookaside protocol session?= That will be required to handle ESN/anti-replay in lookaside > protocol capable PMD as well. Obviously there is no such API for any *-proto devices, see above. Not sure why do you keep repeating it, I already agreed with you, see above= :) Just to summarize: 1. Yes I think for lookaiside/iniline-proto devices there is a need for som= e extra API to sync session state between HW and SW. Right now, I don't have a clear idea how exactly it should look like. 2. Intel team doesn't plan to work on this API right now. 3. I am happy to review with what you guys will come-up with and provide my= feedback. =20 Hope that makes things clear. Konstantin >=20 > > Konstantin > > > > > > > > > Konstantin > > > > > > > > > > > > > > Thanks, > > > > > Anoob > > > > > > > > > > > -----Original Message----- > > > > > > From: dev On Behalf Of Marcin Smoczynski > > > > > > Sent: Wednesday, September 4, 2019 7:47 PM > > > > > > To: konstantin.ananyev@intel.com; akhil.goyal@nxp.com > > > > > > Cc: dev@dpdk.org; Marcin Smoczynski > > > > > > > > > > > > Subject: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: add > > > > > > fallback session > > > > > > > > > > > > Inline processing is limited to a specified subset of traffic. > > > > > > It is often unable to handle more complicated situations, such > > > > > > as fragmented traffic. When using inline processing such traffi= c is > > dropped. > > > > > > > > > > > > Introduce multiple sessions per SA allowing to configure a > > > > > > fallback lookaside session for packets that normally would be d= ropped. > > > > > > A fallback session type in the SA configuration by adding 'fall= back' > > > > > > with 'lookaside-none' or 'lookaside-protocol' parameter to > > > > > > determine type of session. > > > > > > > > > > > > Fallback session feature is available only when using librte_ip= sec. > > > > > > > > > > > > v1 to v2 changes: > > > > > > - disable fallback offload for outbound SAs > > > > > > - add test scripts > > > > > > > > > > > > Marcin Smoczynski (3): > > > > > > examples/ipsec-secgw: ipsec_sa structure cleanup > > > > > > examples/ipsec-secgw: add fallback session feature > > > > > > examples/ipsec-secgw: add offload fallback tests > > > > > > > > > > > > doc/guides/sample_app_ug/ipsec_secgw.rst | 17 +- > > > > > > examples/ipsec-secgw/esp.c | 35 ++-- > > > > > > examples/ipsec-secgw/ipsec-secgw.c | 16 +- > > > > > > examples/ipsec-secgw/ipsec.c | 99 ++++++----= - > > > > > > examples/ipsec-secgw/ipsec.h | 61 +++++-- > > > > > > examples/ipsec-secgw/ipsec_process.c | 113 +++++++---= -- > > > > > > examples/ipsec-secgw/sa.c | 164 ++++++++++= +++----- > > > > > > .../test/trs_aesgcm_common_defs.sh | 4 +- > > > > > > .../trs_aesgcm_inline_crypto_fallback_defs.sh | 5 + > > > > > > .../test/tun_aesgcm_common_defs.sh | 6 +- > > > > > > .../tun_aesgcm_inline_crypto_fallback_defs.sh | 5 + > > > > > > 11 files changed, 358 insertions(+), 167 deletions(-) create > > > > > > mode > > > > > > 100644 > > > > > > examples/ipsec-secgw/test/trs_aesgcm_inline_crypto_fallback_def= s > > > > > > .sh create mode 100644 examples/ipsec- > > > > > > secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh > > > > > > > > > > > > -- > > > > > > 2.21.0.windows.1