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 25F7DA3160 for ; Fri, 11 Oct 2019 17:06:38 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A9AF91EAFD; Fri, 11 Oct 2019 17:06:37 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 905AB1EAF6 for ; Fri, 11 Oct 2019 17:06:35 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2019 08:06:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,284,1566889200"; d="scan'208";a="369443081" Received: from irsmsx109.ger.corp.intel.com ([163.33.3.23]) by orsmga005.jf.intel.com with ESMTP; 11 Oct 2019 08:06:32 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX109.ger.corp.intel.com (163.33.3.23) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 11 Oct 2019 16:06:31 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by irsmsx155.ger.corp.intel.com ([169.254.14.139]) with mapi id 14.03.0439.000; Fri, 11 Oct 2019 16:06:30 +0100 From: "Ananyev, Konstantin" To: Akhil Goyal , "Smoczynski, MarcinX" , "anoobj@marvell.com" CC: "dev@dpdk.org" , "Iremonger, Bernard" Thread-Topic: [PATCH v6 2/4] examples/ipsec-secgw: add fallback session feature Thread-Index: AQHVfQ+ivCALk1qn5kewq+bu97PP/qdVeN8AgAAWDgA= Date: Fri, 11 Oct 2019 15:06:30 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580191975B26@irsmsx105.ger.corp.intel.com> References: <20190927155446.19136-1-marcinx.smoczynski@intel.com> <20191007130254.3064-1-marcinx.smoczynski@intel.com> <20191007130254.3064-3-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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNjRkZjZkMjQtMDZhNC00MzNiLWEzNTYtMGQ5MGE5ODRlZmVjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTndZT0VoUWppYUdYR1BlUFFNUVpia2ZlMGNQQW5oSm1hYmZ3UFl0YmpSekNXbXpFTU1CNldaVXA5Umg2cnArSiJ9 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 v6 2/4] examples/ipsec-secgw: add fallback session feature 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 Akhil, > > > > 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 traffic is dropped. > > > > Introduce fallback session for inline processing allowing processing > > packets that normally would be dropped. A fallback session is > > configured by adding 'fallback' keyword with 'lookaside-none' or > > 'lookaside-protocol' parameter to an SA configuration. > > > > Using IPsec anti-replay window or ESN feature with fallback session is > > not yet supported when primary session is of type > > 'inline-protocol-offload' or fallback session is 'lookaside-protocol' > > because SA sequence number is not synchronized between software and > > hardware sessions. Fallback sessions are also limited to ingress IPsec > > traffic. > > > > Fallback session feature is not available in the legacy mode. > > > I started looking this patch, but some initial thoughts looking at the pa= tch description. >=20 > When you say a fallback session will be a lookaside none or lookaside pro= tocol, > the packet will be processed asynchronously and might as well reorder. Yes, we documented it as one of limitations. Though as I already mentioned for some use-cases some reordering it is acce= ptable. > The best possible solution for this would be the synchronous API which a= re in talks Agree, that would be a way to avoid reordering, but it is not there yet. > in another patchset or use a SW PMD(eg. Openssl etc.) session and wait ti= ll you get the packet dequeued. > So effectively async APIs will be used to behave synchronously. > You can not use hardware PMD session as it will perform very badly for fa= llback packets > Because you have to wait till the packet is not getting dequeued back. We don't plan to support that model because of great performance penalty yo= u mentioned. >=20 > Having said that, you won't find a device or a scenario where you can use > Inline crypto as primary and lookaside proto as fallback. > It can only be like inline crypto as primary and lookaside none as fallba= ck. Yes, correct. I thought that we already removed lookaside-proto from supported types. If we didn't - will certainly do that.=20 >=20 > BTW, I am ok with Patch 1/4 and 3/4. If no objections from the community,= I can pick those. Great to hear. What obstacles do you see with others two? Konstantin >=20 > -Akhil >=20 > > Acked-by: Konstantin Ananyev > > Tested-by: Bernard Iremonger > > Signed-off-by: Marcin Smoczynski > > ---