From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20059.outbound.protection.outlook.com [40.107.2.59]) by dpdk.org (Postfix) with ESMTP id 16CD86CC9 for ; Wed, 19 Oct 2016 10:38:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4ALmzSQpHrX6/I7ejTGZ2EH2xlGrW3T0k2ZMbvnWctE=; b=iK+ULR2qIh+pMoW5YPIo7khFz3TVyzfS0vouOxYUiz8/yUwqgMQ59plGiBADV+Ol/e13mW093534IAd2JpkUFvYvjRVasYwFq3XAHwwZqyvfJwTgCMktepiUreL2XvlQj7h1HTTx5TDETEStJfCV3mzcEdRRPYzykGPaM1syf9I= Received: from DB3PR04MB107.eurprd04.prod.outlook.com (10.242.129.20) by DB3PR04MB106.eurprd04.prod.outlook.com (10.242.129.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.8; Wed, 19 Oct 2016 08:38:13 +0000 Received: from DB3PR04MB107.eurprd04.prod.outlook.com ([169.254.12.205]) by DB3PR04MB107.eurprd04.prod.outlook.com ([169.254.12.205]) with mapi id 15.01.0659.025; Wed, 19 Oct 2016 08:38:14 +0000 From: Akhil Goyal To: "De Lara Guarch, Pablo" , "Gonzalez Monroy, Sergio" , "dev@dpdk.org" Thread-Topic: [PATCH] examples/ipsec-secgw: Update checksum while decrementing ttl Thread-Index: AQHSINzOxjhyRYEH+kmiU3cLMFE9WKChm2mAgAtUIYCAApbI0A== Date: Wed, 19 Oct 2016 08:38:13 +0000 Message-ID: References: <20160926163300.22990-1-akhil.goyal@nxp.com> <53327b5c-9a6f-9336-fbb7-109204a8ff0b@nxp.com> <73f643bf-9ca8-f38a-fbfb-5a127d9d01b5@intel.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [192.88.169.1] x-ms-office365-filtering-correlation-id: f6a8850e-83d5-43dc-bcdb-08d3f7fb4424 x-microsoft-exchange-diagnostics: 1; DB3PR04MB106; 7:3ArOi2lRmw1h5tsSBAvnXgoUJcb43u/YrS0TEMtRjhNHt7IaHrQFbsHVhRk1SuA9YehKwQOS+dX+nABjxEM6shPePSjcSz/N7yemMEY5ahxkKASabDNN4ukqA68yaabi2owXlVqoRMdKGfloHDgMnBrUH55hBiHniaodT+ewb86WzHMvrG7LaK4tMkFwyaa80+JXeeyHvoiDJbU0Env64kLrkDXaAqTlep2mT5s3VCNwQbxzgxvBOuLmK75nNvnJBi3yGCwYd/HvoNH/U0bIHx0ZLn+Jpu8MVjB4NgRQZ5YEc4OMIY4PthzsJ+jLxZBV/opgibaEn8se9xGulvOIS3hWMBMKJeD8BaHEmSSs6s0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR04MB106; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(185117386973197)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DB3PR04MB106; BCL:0; PCL:0; RULEID:; SRVR:DB3PR04MB106; x-forefront-prvs: 0100732B76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(43544003)(76104003)(24454002)(377454003)(13464003)(10400500002)(102836003)(6116002)(3846002)(15650500001)(7736002)(3660700001)(105586002)(2950100002)(3900700001)(9686002)(8936002)(5002640100001)(2900100001)(3280700002)(189998001)(7696004)(5001770100001)(122556002)(76576001)(87936001)(68736007)(97736004)(2906002)(92566002)(106116001)(106356001)(305945005)(86362001)(76176999)(586003)(66066001)(81156014)(33656002)(93886004)(19580395003)(19580405001)(5660300001)(107886002)(101416001)(81166006)(8676002)(50986999)(54356999)(74316002)(2501003)(7846002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR04MB106; H:DB3PR04MB107.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2016 08:38:14.0078 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR04MB106 Subject: Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: Update checksum while decrementing ttl X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 08:38:16 -0000 -----Original Message----- From: De Lara Guarch, Pablo [mailto:pablo.de.lara.guarch@intel.com]=20 Sent: Monday, October 17, 2016 10:35 PM To: Gonzalez Monroy, Sergio ; Akhil Goyal= ; dev@dpdk.org Subject: RE: [PATCH] examples/ipsec-secgw: Update checksum while decrementi= ng ttl > -----Original Message----- > From: Gonzalez Monroy, Sergio > Sent: Monday, October 10, 2016 5:05 AM > To: De Lara Guarch, Pablo; Akhil Goyal; dev@dpdk.org > Subject: Re: [PATCH] examples/ipsec-secgw: Update checksum while=20 > decrementing ttl >=20 > On 07/10/2016 21:53, De Lara Guarch, Pablo wrote: > >> -----Original Message----- > >> From: Akhil Goyal [mailto:akhil.goyal@nxp.com] > >> Sent: Tuesday, October 04, 2016 11:33 PM > >> To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio; dev@dpdk.org > >> Subject: Re: [PATCH] examples/ipsec-secgw: Update checksum while=20 > >> decrementing ttl > >> > >> On 10/5/2016 6:04 AM, De Lara Guarch, Pablo wrote: > >>> > >>>> -----Original Message----- > >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Sergio > Gonzalez > >>>> Monroy > >>>> Sent: Monday, September 26, 2016 6:28 AM > >>>> To: akhil.goyal@nxp.com; dev@dpdk.org > >>>> Subject: Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: Update > checksum > >>>> while decrementing ttl > >>>> > >>>> Hi Akhil, > >>>> > >>>> This application relies on checksum offload in both outbound and > >> inbound > >>>> paths (PKT_TX_IP_CKSUM flag). > >> [Akhil]Agreed that the application relies on checksum offload, but=20 > >> here we are talking about the inner ip header. Inner IP checksum=20 > >> will be updated on the next end point after decryption. This would=20 > >> expect that the next end point must have checksum offload=20 > >> capability. What if we are capturing the encrypted packets on=20 > >> wireshark or say send it to some other machine which does not run=20 > >> DPDK and do not know about > checksum > >> offload, then wireshark/other machine will not be able to get the=20 > >> correct the checksum and will show error. >=20 > Understood, we need to have a valid inner checksum. > RFC1624 states that the computation would be incorrect in=20 > corner/boundary case. > I reckon you are basing your incremental update on RFC1141? >=20 > Also I think you should take care of endianess and increment the=20 > checksum with > host_to_be(0x0100) instead of +1. >=20 > >>>> Because we assume that we always forward the packet in both=20 > >>>> paths, > we > >>>> decrement the ttl in both inbound and outbound. > >>>> You seem to only increment (recalculate) the checksum of the=20 > >>>> inner IP header in the outbound path but not the inbound path. > >> [Akhil]Correct I missed out the inbound path. > >>>> Also, in the inbound path you have to consider a possible ECN=20 > >>>> value > >> update. > >> [Akhil]If I take care of the ECN then it would mean I need to=20 > >> calculate the checksum completely, incremental checksum wont give corr= ect results. > >> This would surely impact performance. Any suggestion on how should=20 > >> we take care of ECN update. Should I recalculate the checksum and=20 > >> send the patch for ECN update? Or do we have a better solution. >=20 > If I am understanding the RFCs mentioned above correctly, you should=20 > be able to do incremental checksum update for any 16bit field/value of=20 > the IP header. > I don't see no reason why you couldn't do something like that, except=20 > that you would have to follow the full equation instead of just adding=20 > 0x0100, which would be always the case when decrementing TTL. >=20 > What do you think? Any comments, Akhil? Ok.. will send next version soon.