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 21D7DA0613 for ; Thu, 26 Sep 2019 14:38:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8DF205B32; Thu, 26 Sep 2019 14:38:27 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id F10784C99 for ; Thu, 26 Sep 2019 14:38:25 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2019 05:38:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,551,1559545200"; d="scan'208";a="273312433" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga001.jf.intel.com with ESMTP; 26 Sep 2019 05:38:23 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by IRSMSX106.ger.corp.intel.com ([169.254.8.184]) with mapi id 14.03.0439.000; Thu, 26 Sep 2019 13:38:22 +0100 From: "Ananyev, Konstantin" To: Anoob Joseph , "Smoczynski, MarcinX" , "akhil.goyal@nxp.com" CC: "dev@dpdk.org" , Jerin Jacob Kollanukkaran , Narayana Prasad Raju Athreya , Archana Muniganti Thread-Topic: [dpdk-dev] [PATCH v3 0/3] add fallback session Thread-Index: AQHVcgRpybp7qxFpeEujftbhitMyNac9nfaAgAA+IYA= Date: Thu, 26 Sep 2019 12:38:20 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258019196B087@irsmsx105.ger.corp.intel.com> References: <20190904141642.14820-1-marcinx.smoczynski@intel.com> <20190923114415.17932-1-marcinx.smoczynski@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGZjMmVmYmQtYTE0Ni00MThmLThiMDgtOGZkNzI5ZDYyNTZmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTWRKeG5FZ0JNNnlxWldjS1pYNHBjOTBETzRjOFArbU9ZaEdpOFM5VzlUdkNDdzRia2xwZHBqclFaMG1ycUc0bSJ9 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] [PATCH v3 0/3] 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, Answers/comments inline. Marcin, please correct me, if I missed something. Konstantin >=20 > Hi Marcin, Konstantin, >=20 > I've few more observations regarding the proposed feature. >=20 > 1. From what I understood, if an ESP packet ends up on an unprotected int= erface and doesn't have 'PKT_RX_SEC_OFFLOAD' bit set, then the > packet would be looked up to see the associated SA and then fallback sess= ion is figured out and then further processing is done. >=20 > Can you confirm if I understood the sequence correctly? If yes, then aren= 't we doing an extra lookup in the s/w? The packet may be looked > by the h/w using rte_flow and that information could be used to determine= the SA. Also, if the ESP packet is expected to be forwarded, then > the above logic will add an unnecessary lookup even after your h/w has de= tected that the packet need not be security processed. Not sure I understood your whole statement above. AFAIK, right now (with dpdk master) for unprotected iface it works like tha= t: 1. slit incoming traffic into 3 groups: ESP packets, IPv4 packets, IPv6 pa= ckets. For ESP packets:=20 2. perform SAD lookup a. if it fails (non SA found for that SPI), then drop the packet. b. otherwise (SA found) process the packet using found SA What fall-back patch adds: Before step 2.b check: does that SA has its primary session with type INLINE-CRYPTO and =20 does HW fail to do IPsec realted processing for it (by some reason)? If yes, then mark this packet to be processed by fall-back session. if (MBUF_NO_SEC_OFFLOAD(pkt) && sa->fallback_sessions > 0) { uintptr_t intsa =3D (uintptr_t)sa; intsa |=3D IPSEC_SA_OFFLOAD_FALLBACK_FLAG; result_sa =3D (void *)intsa; } So from my perspective, no additional lookup where introduced. Also AFAIK, right now there is no possibility to configure ipsec-secgw to BYPASS some ESP traffic. Should we do it (to conform to ipsec RFC) - that's probably subject of another discussion. =20 >=20 > 2. The solution proposed here seems like adding the handling in ipsec-sec= gw instead of ipsec library. In other words, this feature is not > getting added in ipsec library, which was supposed to simplify the whole = ipsec usage in DPDK, but fails to handle the case of fragmentation. What we have right now with ipsec library is SA (low) level API. It can handle multi-segment packets properly, but expects someone else to d= o other steps (fragmentation/reassembly). ipsec-secgw demonstrates how librte_ip_frag and librte_ipsec can be used to= gether to deal with fragmented IPsec traffic in a proper manner. Probably in future we'll consider adding some high-level API that will be a= ble to do whole processing under hood (SPD/SAD lookup, fragment/reassembly, actual IPsec packet processing, match= ing inbound selectors, etc.), but right now it is not the case. =20 > Also, since the fallback feature is entirely done in the application, it = begs the question why the same feature is omitted for legacy use case. Because legacy mode doesn't support multi-seg packets at first place. Also it is an extra overhead to support 2 code-paths (legacy and library) for the same app, so we'd like in future to deprecate and later remove lega= cy code-path. As a first step we propose to make library code-path a default one: http://patches.dpdk.org/cover/58247/ >=20 > 3. It seems like ordering won't be maintained once this processing is don= e. Again, this is the sequence I understood. Please correct me if I > missed something, > a. Application receives a bunch of packets (let's say 6 packets), = in which few are fragmented (P3 & P4) and the rest can be inline > processed. > b. Application receives P1->P2->P3->P4->P5->P6 (in this, P1, P2, P= 5, P6 are inline processed successfully) and P4 & P5 are the fragments > c. Application groups packets. P1->P2->P5->P6 becomes one group an= d P3->P4 becomes another and goes for fallback processing. > Now how is ordering maintained? I couldn't figure out how that is done in= this case. You right, fallback session can introduce packet reordering. At least till we'll have ability to process packets in sync mode too. See our presentation at dpdk userspace (slides 17, 18): https://static.sched.com/hosted_files/dpdkbordeaux2019/8f/DPDK-IPSECu9.pdf Right now the only way to deal with it - have replay window big enough to s= ustain reordering and async processing latency. That's actually another reason why we add this feature into ipsec-secgw sam= ple app: so people can evaluate it on their platforms, determine what replay window = size would be needed, what issues/slowdowns it might cause, etc. >=20 > Thanks, > Anoob >=20 > > -----Original Message----- > > From: dev On Behalf Of Marcin Smoczynski > > Sent: Monday, September 23, 2019 5:14 PM > > To: Anoob Joseph ; akhil.goyal@nxp.com; > > konstantin.ananyev@intel.com > > Cc: dev@dpdk.org; Marcin Smoczynski > > Subject: [dpdk-dev] [PATCH v3 0/3] add fallback session > > > > Add fallback session feature allowing to process packets that inline pr= ocessor > > is unable to handle (e.g. fragmented traffic). Processing takes place i= n a > > secondary session defined for SA in a configuration file. > > > > This feature is limited to ingress IPsec traffic only. IPsec anti-repla= y window > > and ESN are supported in conjunction with fallback session when followi= ng > > conditions are met: > > * primary session is 'inline-crypto-offload, > > * fallback sessions is 'lookaside-none'. > > > > v2 to v3 changes: > > - doc and commit log update - explicitly state feature limitations > > > > 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 | 20 ++- > > 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, 361 insertions(+), 167 deletions(-) create mode 100= 644 > > examples/ipsec-secgw/test/trs_aesgcm_inline_crypto_fallback_defs.sh > > create mode 100644 examples/ipsec- > > secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh > > > > -- > > 2.17.1