From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18636FA3728 for ; Wed, 16 Oct 2019 10:37:23 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id B079120872 for ; Wed, 16 Oct 2019 10:37:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B079120872 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 175901D443; Wed, 16 Oct 2019 12:37:22 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 5405C1D3F0 for ; Wed, 16 Oct 2019 12:37:20 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2019 03:37:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,303,1566889200"; d="scan'208";a="202038466" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by FMSMGA003.fm.intel.com with ESMTP; 16 Oct 2019 03:37:18 -0700 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by irsmsx110.ger.corp.intel.com (163.33.3.25) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 16 Oct 2019 11:37:16 +0100 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.252]) by irsmsx111.ger.corp.intel.com ([169.254.2.123]) with mapi id 14.03.0439.000; Wed, 16 Oct 2019 11:37:16 +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/qdVeN8AgAAWDgCABjEdAIABXJsw Date: Wed, 16 Oct 2019 10:37:16 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725801A8C696D4@IRSMSX104.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> <2601191342CEEE43887BDE71AB9772580191975B26@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiN2I0MTdlYTQtODhmZS00MTgzLThiODctOTU5ZDExMTRkNzY4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiSzhNbHh4RThQVEo4MExnY0VvdEVhUm1aT0UyRTUyQWJoc2lrSGppTDRDSEUwaGF0Z0pMbUpWZHJKTTdCNHowRiJ9 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" > > > > Inline processing is limited to a specified subset of traffic. It i= s > > > > often unable to handle more complicated situations, such as fragmen= ted > > > > traffic. When using inline processing such traffic is dropped. > > > > > > > > Introduce fallback session for inline processing allowing processin= g > > > > 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-protoco= l' > > > > because SA sequence number is not synchronized between software and > > > > hardware sessions. Fallback sessions are also limited to ingress IP= sec > > > > traffic. > > > > > > > > Fallback session feature is not available in the legacy mode. > > > > > > > I started looking this patch, but some initial thoughts looking at th= e patch > > description. > > > > > > When you say a fallback session will be a lookaside none or lookaside= protocol, > > > 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 > > acceptable. >=20 > Which usecases allow reordering. AFAIK, VoIP, video-streaming, netflow/ipfix, some P2P protocols - all of t= hem tolerate packet reordering. Actually modern TCP implementations are also quite robust to packet reorder= ings (till some extent of course). > I think most stacks have replay window of less than 256/128 frames. >From our measurements, on IA boxes, ~256 seems good enough for many cases.= =20 > > > > > The best possible solution for this would be the synchronous API whi= ch are 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 wai= t till 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 fo= r > > fallback 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 penalt= y you > > mentioned. >=20 > So what is currently supported with this patchset. > - cpu crypto is not there yet. > - SW PMD you are not supporting that model. ixbge(inline-crypto)+qat(lksd-crypto) >=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 fa= llback. > > > > Yes, correct. > > I thought that we already removed lookaside-proto from supported types. > > If we didn't - will certainly do that. > > > > > > > > BTW, I am ok with Patch 1/4 and 3/4. If no objections from the commun= ity, I > > can pick those. > > > > Great to hear. > > What obstacles do you see with others two? > I believe there are some discussion going on between you and Anoob. Seems too vague... Anything concrete? Konstantin