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 7648FA04AB; Wed, 6 Nov 2019 14:55:42 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4CD551C1E1; Wed, 6 Nov 2019 14:55:42 +0100 (CET) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id D975F1C1D9; Wed, 6 Nov 2019 14:55:40 +0100 (CET) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA6DoN2R002042; Wed, 6 Nov 2019 05:55:40 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=sHujfRt8glkQrMoK9WNZMB1WmGY1OAi5hHt+lX2T1MU=; b=e5/pu9gHQpVqEXLiUjfZj4ArT/ykWqk2kQQVHLYWBnZA+gU4LfOCJwVymim8s1Uj8zy1 pYlXbvbqlPK+xFfEJ6kWfMpR7oR53VRC8oBqpsn6B5ngjJac05UrZ9bj8f9OjqiVys4h yC2i7/imwZtMoJyEmQDNFNNcVMs/6NMd9IbeSBSrtFu7WzRQxbtjVVY3+ZuOAO+GOmtN zr6kc1F1KeQKnvVtn2qiaz2DXLXXd8zOlO/0OMSoUTrzV3RSVOFkcunuwF4Kdu/2tDWR qiW6Zt6D3Kld6TBXpNL4sTKvIkVGve7R7PJAMiYxA/Tuy+RSsM1ye44Yd/XrueqCOrb+ cA== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2w3eud45ps-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 06 Nov 2019 05:55:39 -0800 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 6 Nov 2019 05:55:39 -0800 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.53) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 6 Nov 2019 05:55:38 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lCVMlvrx5np8x4aU1mxfvuZ2p5MJh0r9T6lBtJtvmSfqobsbPW50fQD96VOYXpgoXns97C//6w3zChJHi4MBwgWTCSAFVTiQeFaCe0UsovETm00w3izO4tHS5ID77sDvbFMfUDoxLdGmSjtb4Re2MB/DLFXhB2F/vfAuZnp5wPAlC1LOEJhPDjlKrnLNPp1r0XPyw9QGFn5iX+7RZI/nwonrsmHdfwTbjNe5oO/+NhCoDKXykh972pgVGuGd7b62ppVFBOVDM3ALDOrm2cQLzsm6oZH4Ult5bes/jlLQoatffCaTcNNeSOmFHgYh/pMIo2yf3sCAV86QnuyraA/bSw== 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=sHujfRt8glkQrMoK9WNZMB1WmGY1OAi5hHt+lX2T1MU=; b=IagAUGGAfPASohaIwwqSax2tFKcZD8qichisClU1CMcImks/T14vEb0bPQM1Hdxppo7gM1IzritOMLmtY5aDhUHCGY0nkxsWooZMsbADl4DA5C4unrlr6OGZFd5bRBvvx0uYzBIbyJi5p1DgwQHbWXUP7dWxm8FuEOxjVjcZD00lBXVGjbpnjlh6N5JnAjVGkdv5yji5D6bXWc4+zu1Yvd/I/iM7dSl+bEhgK7Uw16mZRDoOVC2d8sAwSjZrJqCiWE3Om8I0G5LC58f7j3hOzZx188a+3cwd2IXskJQaaVAdkEIEJeXWZVz8c/iLFkN8jjGyQcofyPrcQx7tNZ9i3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sHujfRt8glkQrMoK9WNZMB1WmGY1OAi5hHt+lX2T1MU=; b=XByRZSwJYN3pTBrVxGC8PjGXbgaluDsOwnIwwztZo8ZP4OPXCyFuYCJ0LbktrhgfMt++2z7oE7dJEymkZlmioErw0IqS7CeQA3g37r68MBMW56SgkttuHhyfJUDaoLZn1MRdZ+begVIrrCPIv/TJe3DWpDJu3vqo5K0DWSm4CzM= Received: from MN2PR18MB2877.namprd18.prod.outlook.com (20.179.20.218) by MN2PR18MB3405.namprd18.prod.outlook.com (10.255.237.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.22; Wed, 6 Nov 2019 13:55:37 +0000 Received: from MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::10fb:1671:dbff:6710]) by MN2PR18MB2877.namprd18.prod.outlook.com ([fe80::10fb:1671:dbff:6710%4]) with mapi id 15.20.2408.025; Wed, 6 Nov 2019 13:55:37 +0000 From: Anoob Joseph To: "Ananyev, Konstantin" , 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: AQHVgyO/HclXzaWKIUOFWML0jPbva6dbZeWAgABntICAFzVOAIADZOMAgATZ2gCAASl0oA== Date: Wed, 6 Nov 2019 13:55:37 +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: <2601191342CEEE43887BDE71AB97725801A8C7F304@IRSMSX104.ger.corp.intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [115.113.156.3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cb13621f-403a-452e-5b01-08d762c10087 x-ms-traffictypediagnostic: MN2PR18MB3405: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(366004)(39860400002)(376002)(136003)(189003)(199004)(53754006)(13464003)(43544003)(478600001)(229853002)(14454004)(99286004)(8936002)(26005)(186003)(25786009)(3846002)(6116002)(4326008)(66066001)(316002)(110136005)(256004)(2906002)(14444005)(54906003)(71190400001)(81156014)(305945005)(7696005)(76176011)(74316002)(55236004)(66556008)(6506007)(66946007)(52536014)(66446008)(64756008)(53546011)(102836004)(76116006)(5660300002)(66476007)(6246003)(9686003)(55016002)(7736002)(486006)(446003)(8676002)(476003)(11346002)(86362001)(71200400001)(33656002)(81166006)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR18MB3405; H:MN2PR18MB2877.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RfYL+OATnvbKfeD201Lpb0KS+t7CdwjpsDdqtacGDHCi6oxO/TgIoWS9aGY5x9E96tr3U6VNJnN2mEKWFXlXIknCGePcry0n1sm62JIMy+lXoeDPHrQrF5xTZkjKnrr189jcQ6U9HBzdDM8ceC9E7SIsdkKaVEluGuUr1GJWYBtU1CoojFLPRiDj4xI5yQBHdfa0VCvmro8HonaqTl7t/9NhA/r5LvME0AuAR54+vNFzP9zUA7aLs/W5REUGap3jYiFVwiaGUvdVm72WxK4/rwccursKm0ZOBl/nYHAuvk1jVqZP5FgODT4erfwAdUgXVrPByejMr/uigozC0nxPs/K2nBRFHe4w1AfluhIZ19rXXEHOIqRT7Rnv/QDAPcG67e8Jt10TjWQJmtZ0TRdaJ9mUkisVmOFsSmhTgIG1jCsU3WsvWAvuZkDD25v+5TuI Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cb13621f-403a-452e-5b01-08d762c10087 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 13:55:37.1396 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uajy+qbFuRhzoF7+C2lL3mGM+EuQi5O55gDBgNGHd6oiHijkLQikFUQ4GOBNUii+l6af3WTyHU5nA0pzZzaKzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB3405 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-06_04:2019-11-06,2019-11-06 signatures=0 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" Hi Akhil, Konstantin, Please see inline. Thanks, Anoob > -----Original Message----- > From: Ananyev, Konstantin > Sent: Monday, November 4, 2019 8:55 PM > To: Akhil Goyal ; Iremonger, Bernard > ; Thomas Monjalon > Cc: dev@dpdk.org; Anoob Joseph ; Jerin Jacob > Kollanukkaran ; dpdk-techboard > Subject: [EXT] RE: [PATCH v2 0/3] examples/ipsec-secgw: set default >=20 > External Email >=20 > ---------------------------------------------------------------------- > Hi Akhil, >=20 > > > > > > > > > > > > > > 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 the > > > > > > performance > > > > numbers. > > > > > > > > > > Could you give some details on the performance issues you are see= ing. > > > > > > > > > > > > > We were observing about 4-5% drop when using the ipsec-lib instead > > > > of the Legacy code path. We would again measure it on RC1. That is > > > > why I say, I will Hold this patch till RC2, unless some other vendo= r 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 base= on > NXP hardware. > > > > We cannot merge this. Anoob also reported performance issues on Marvell > hardware. >=20 > 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 s= ome > effort from all interested parties (Intel, NXP, Marvell, ...). > If everyone is ok with it, then I think it would be good to have some dra= ft > timeline here. > If you guys are not interested in this effort, then the only other approa= ch I can > think about: [Anoob] I would say this is the right option. But then, there are features = getting added only to lib ipsec mode. There are features like "fallback ses= sion" 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 lib ipsec mode, the perf diver= gence between lib ipsec mode and non lib ipsec mode is fairly obvious. So what is the solution? Both the modes need to be at par if our end strate= gy is going to deprecate one. If we need to reach a state where we can do a= pples to apples comparison, new features should be added to both modes and = there should be a consensus on the feature implementations. Also, looking at the "fallback session" feature, the feature was "pushed" w= ithout properly addressing the issues. The solution was hardly suitable for= inline ipsec and the comments were ignored. Marvell is not ok with adding = checks in datapath for an incomplete feature. Marvell withdrew the objectio= ns when it was conveyed that the review comments were deemed invaluable. Al= so because it was added to lib ipsec path which is not being used currently= for our benchmarks. Marvell will be submitting an RFC for supporting fallb= ack session with few changes in the rte_security library. When we attempt t= hat, we can take care of only non lib ipsec mode as lib ipsec mode already = has one and Marvell cannot work on two different fronts, when the other con= tributors themselves don't care about other established modes.=20 Also considering that lib ipsec is under constant change, (and is still exp= erimental), I would not be too excited about making it the default immediat= ely. I see that there are usages supported by the non lib ipsec mode, which= is not supported by lib ipsec mode. For example, ipv4 & ipv6 using same SPI is valid for non lib ipsec, but not= for lib ipsec. Because of this, the default conf doesn't even run when lau= nched with lib ipsec mode. I'm not sure whether we should rush with making = it the default when the whole idea is still "experimental". > 2. split ipsec-secgw app into 2 (one using librte_ipsec, second using raw= 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 clea= r > decision, one way or another. >=20 > Thanks > Konstantin >=20 >=20 >=20 >=20 >=20