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 1DC14A04B3; Mon, 18 Nov 2019 14:03:20 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 40EB0B62; Mon, 18 Nov 2019 14:03:19 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id DFFFCA69; Mon, 18 Nov 2019 14:03:17 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2019 05:03:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,320,1569308400"; d="scan'208";a="231158387" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by fmsmga004.fm.intel.com with ESMTP; 18 Nov 2019 05:03:15 -0800 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 18 Nov 2019 05:03:15 -0800 Received: from orsmsx604.amr.corp.intel.com (10.22.229.17) by ORSMSX607.amr.corp.intel.com (10.22.229.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 18 Nov 2019 05:03:15 -0800 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by orsmsx604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Mon, 18 Nov 2019 05:03:15 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (104.47.33.58) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 18 Nov 2019 05:03:15 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BrzjgD/FEHf45bnntJN/Im/+Bw2ANyrRVdux3CxXtTXUtiAguT8xvBwlCakO1uSaVnS6BUjz3BJqIyerNekYZ7NCj0srHhrL9bCC+w5CpMhgDNK+OFMJhBpDP5jZp63mdMwm8XtCU8PE5xVIdFmCADYdlZODwkm4SaKvQZQ2siUMB84s7X3T0TvuOJ0un/0jY+8iAhNhAPhSuO4LEXVpv29qTuiKlZyTGmT6jN/2mKeC/uZtTZIx+SmAQTg+XrBDfuBKdEypCGoaL2g6KW4UFMCJ7t9dxtbVm2riVJ4cJQbLiiHK5HwqxwH+gHaYNadblqRLzAB536IwsHEgurBTjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e/m0GqnJKr1Lal391KJ0jB2QQCW95dxktUpm7XlOdpk=; b=cISh6yDIoxIONYqvsmNXk5LrPx2ZXavd7RjKMmP9GC4r369mKwFvTB85anuEwAQKOOyzLqPCOSC2trw7xKeuOvfBN6IdeEqtufRzNgNFzcqgaDnq650ItwPJk0KLN+8JHbT/ZIYaJwi61OIH5tTSZXW1Ge8mCd9KDRlRfam2L7+TYYgxmbK6usxXEuXoNcdfUh68LdVNblKaxCoWbF3+l4KSPSJGJ/eUX0MrDqhxFD7ao7WVUyUGKH8R8JQYYkooNkhDOLeJW/KzcYG30RKTOJaYt5N+YRCNwm8BE7rAryofoi4/xfUGc3QyeEezYJwDagzRlI+3NNAL0nyOBOcTnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e/m0GqnJKr1Lal391KJ0jB2QQCW95dxktUpm7XlOdpk=; b=HEw2pW2BGbyD2wI/p1VUKrrnSYhPzd7lZFLbb1ltntoRTrQN7urfJ8HWoO44zljHtvAwafht2PONUxO51QpL6lsbqWyt7mOqDWsOyVuw63IL55NncRJ5Szb8s5PFZNwBbAMzuLPl3ng3hip/U9KO3IKb0o/QMN/ImanhfoN9y6E= Received: from SN6PR11MB2558.namprd11.prod.outlook.com (52.135.91.13) by SN6PR11MB2591.namprd11.prod.outlook.com (52.135.91.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.22; Mon, 18 Nov 2019 13:03:12 +0000 Received: from SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::19a4:37bc:d979:dd76]) by SN6PR11MB2558.namprd11.prod.outlook.com ([fe80::19a4:37bc:d979:dd76%5]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 13:03:12 +0000 From: "Ananyev, Konstantin" To: Anoob Joseph , Akhil Goyal , "Iremonger, Bernard" , Thomas Monjalon CC: "dev@dpdk.org" , Jerin Jacob Kollanukkaran , dpdk-techboard Thread-Topic: [PATCH v2 0/3] examples/ipsec-secgw: set default Thread-Index: AQHVeGt1PghzvMyi1UGof2wAAdzVAqdVYHmAgAAtjwCABbfQAIAAJLqAgABntICAF0YRAIADZOMAgATMzlCAAxjcgIASzCTQ Date: Mon, 18 Nov 2019 13:03:12 +0000 Message-ID: References: <1567069173-10505-1-git-send-email-bernard.iremonger@intel.com> <1569943080-20228-1-git-send-email-bernard.iremonger@intel.com> <5630388.AILYuOXkcA@xps> <8CEF83825BEC744B83065625E567D7C260E0E213@IRSMSX108.ger.corp.intel.com> <8CEF83825BEC744B83065625E567D7C260E14C88@IRSMSX108.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725801A8C7F304@IRSMSX104.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzgyMmQzMzMtZDNmZS00Yjg5LTgxOGUtYzgyMTZlNThkZTc0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZEE1VzRUTDIzQWk0ZTJyVXdOdCtpT3hkNGkrSUlsTkp2U2tTSkIrYndZd0ttK2JtMkIxZWlPd2JwVzhrWEQrRSJ9 dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 x-ctpclassification: CTP_NT authentication-results: spf=none (sender IP is ) smtp.mailfrom=konstantin.ananyev@intel.com; x-originating-ip: [192.198.151.185] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a0c9fbb4-af39-4cbc-8cf1-08d76c27ab39 x-ms-traffictypediagnostic: SN6PR11MB2591: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(136003)(346002)(376002)(189003)(199004)(43544003)(53754006)(256004)(86362001)(6246003)(54906003)(476003)(8936002)(26005)(25786009)(5660300002)(11346002)(66476007)(66946007)(102836004)(6436002)(9686003)(186003)(66446008)(76116006)(64756008)(81156014)(81166006)(8676002)(66556008)(55016002)(66066001)(33656002)(478600001)(14444005)(52536014)(74316002)(6506007)(229853002)(446003)(486006)(316002)(6116002)(3846002)(7696005)(110136005)(4326008)(71200400001)(2906002)(99286004)(76176011)(7736002)(71190400001)(14454004)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR11MB2591; H:SN6PR11MB2558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zkiMQrjsGTr54rZjbIDFMjvzkUBISvEW0HM8st2h/O+XLX/PWCYCni3Csbp/ZKewmGmmEzMUxUpaxTIGGmGVEfrfqtUpDmXzEYR8qAjTJau29dvhZmD5y7ECiPIrb3YXklmHSrS80pQvS+rDhWv0NY38ZtpM9i2/6Qmyu5zTJe+1up11yvc50vd2NJpNG9trwayAZHaKPKnIs9FAsAO7WpRiraPaRIyEK18UgdZ+gNXjmEf9a2A4zYKDZvI2oDQzmp7wUDfiSumdNFAhcRG/WLMHTSzVkICpMCPx0BmBXw5K/4ih+7f+5Vqslz34y1KuS1uNEvtDiP7kIyV5CaTgwhXD8Y3Ntdm2e5KFI6ICa/Iy5KmKj+N7tNINxA4i1bwrKh6QXAhVXl9IOMNOhbD90NTusWFrHzw9d12diI1Zdzivjz8oJc3pV/LB9cwEpcfh Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a0c9fbb4-af39-4cbc-8cf1-08d76c27ab39 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 13:03:12.7055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NhzWsLq+K8giOXaQ0dE9+NC+PAWOs/BsXNIdczLmIFRflXB9AAfTi6kldh/LkZtX6P0og+j261rMlnN3W9QxXxPHlrZZAMV2K1h7QdBNrnk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2591 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v2 0/3] examples/ipsec-secgw: set default 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" > > > > > > > > > > > > > > > > 11/10/2019 14:40, Akhil Goyal: > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > This patchset would need ack from more vendors as it will > > > > > > > > > impact user > > > > > > > > experience > > > > > > > > > on a key example application which is normally > > > > > > > > > demonstrated to > > > > > > > customers. > > > > > > > > > > > > > > > > > > IPSec library is still evolving and there are new > > > > > > > > > functionality added every > > > > > > > > release. > > > > > > > > > Atleast from NXP side we are not OK with this change. > > > > > > > > > > > > > > > > What can be changed in the library to make it acceptable as > > > > > > > > a default in this example? > > > > > > > > > > > > > > > > > > > > > > We are observing performance issues with ipsec library. So > > > > > > > would request other Vendors to confirm if they are OK with th= e > > > > > > > performance > > > > > numbers. > > > > > > > > > > > > Could you give some details on the performance issues you are s= eeing. > > > > > > > > > > > > > > > > We were observing about 4-5% drop when using the ipsec-lib instea= d > > > > > of the Legacy code path. We would again measure it on RC1. That i= s > > > > > why I say, I will Hold this patch till RC2, unless some other ven= dor also > > confirms that. > > > > > > > > Is there any update on performance measurements on 19.11-rc1 ? > > > > > > > The performance impact of this patch is huge ~10% w.r.t. 19.11-rc1 ba= se on > > NXP hardware. > > > > > > We cannot merge this. Anoob also reported performance issues on Marve= ll > > hardware. > > > > Sure, 10% is a lot, so more than understandable. > > Though, I think we do need to decide our future goals for it. > > I see two main options here: > > 1. Make lib code-path on par with legacy one in terms of performance, > > deprecate and then remove legacy code-path. > > Till that happen (deprecation/removal) to minimize code divergence= , > > forbid to add new features to legacy code path only. > > New features should be added to both paths, or library code path. > > Obviously that one looks like a preferred option to me, but it requires= some > > effort from all interested parties (Intel, NXP, Marvell, ...). > > If everyone is ok with it, then I think it would be good to have some d= raft > > timeline here. > > If you guys are not interested in this effort, then the only other appr= oach I can > > think about: >=20 > [Anoob] I would say this is the right option. But then, there are feature= s getting added only to lib ipsec mode. There are features like > "fallback session" or anti replay which is only added for lib ipsec mode = and not for non lib ipsec mode. Such features are good to have > but would cost extra cycles in the datapath. Since it is only added for l= ib ipsec mode, the perf divergence between lib ipsec mode and > non lib ipsec mode is fairly obvious. AFAIK, all these features are optional and can be disabled. For performance comparison, I'd expect we run lib mode with extra features = disabled.=20 >=20 > So what is the solution? Both the modes need to be at par if our end stra= tegy is going to deprecate one. If we need to reach a state > where we can do apples to apples comparison, new features should be added= to both modes and there should be a consensus on the > feature implementations. >=20 > Also, looking at the "fallback session" feature, the feature was "pushed"= without properly addressing the issues. The solution was > hardly suitable for inline ipsec and the comments were ignored. Marvell i= s not ok with adding checks in datapath for an incomplete > feature. Marvell withdrew the objections when it was conveyed that the re= view comments were deemed invaluable. Also because it > was added to lib ipsec path which is not being used currently for our ben= chmarks. Marvell will be submitting an RFC for supporting > fallback session with few changes in the rte_security library. When we at= tempt that, we can take care of only non lib ipsec mode as lib > ipsec mode already has one and Marvell cannot work on two different front= s, when the other contributors themselves don't care > about other established modes. >=20 > Also considering that lib ipsec is under constant change, (and is still e= xperimental), I would not be too excited about making it the > default immediately. I see that there are usages supported by the non lib= ipsec mode, which is not supported by lib ipsec mode. >=20 > For example, ipv4 & ipv6 using same SPI is valid for non lib ipsec, but n= ot for lib ipsec. Because of this, the default conf doesn't even > run when launched with lib ipsec mode. I'm not sure whether we should rus= h with making it the default when the whole idea is still > "experimental". >=20 > > 2. split ipsec-secgw app into 2 (one using librte_ipsec, second using r= aw devices > > (legacy one)). > > We probably can still try to keep some code shared by 2 apps: > > (configuration/initialization/session management (SAD, SPD)), > > but actual packet processing path will be different. > > I really don't like that option, but I think we need to come-up with cl= ear > > decision, one way or another. > > > > Thanks > > Konstantin > > > > > > > > > >