From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 8B0F8BB08 for ; Wed, 26 Oct 2016 04:29:33 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP; 25 Oct 2016 19:29:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,548,1473145200"; d="scan'208";a="894008214" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by orsmga003.jf.intel.com with ESMTP; 25 Oct 2016 19:29:31 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.210]) by IRSMSX106.ger.corp.intel.com ([169.254.8.99]) with mapi id 14.03.0248.002; Wed, 26 Oct 2016 03:29:30 +0100 From: "De Lara Guarch, Pablo" To: Akhil Goyal , "Gonzalez Monroy, Sergio" , "dev@dpdk.org" Thread-Topic: [PATCH] examples/ipsec-secgw: Update checksum while decrementing ttl Thread-Index: AQHSHtJJ2RZYZPK2TU2VpeQvRbL0OaCdZMYwgAQp9YCAC2S5QIAChmWAgAqpxhA= Date: Wed, 26 Oct 2016 02:29:30 +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-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjFiOTdjMmItMzQ1NS00ZDEwLWE0YzktN2YyMGZlMjY1MTU4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlhnZHJIWWVXa1pMR3F1UHg3ZDd3YllMMWZmWWhCK0tNVzVUYTZxNStyNjg9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 26 Oct 2016 02:29:34 -0000 > -----Original Message----- > From: Akhil Goyal [mailto:akhil.goyal@nxp.com] > Sent: Wednesday, October 19, 2016 1:38 AM > To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio; dev@dpdk.org > Subject: RE: [PATCH] examples/ipsec-secgw: Update checksum while > decrementing ttl >=20 >=20 >=20 > -----Original Message----- > From: De Lara Guarch, Pablo [mailto:pablo.de.lara.guarch@intel.com] > 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 > decrementing ttl >=20 >=20 >=20 > > -----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 > > decrementing ttl > > > > 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 > > >> 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 > > >> here we are talking about the inner ip header. Inner IP checksum > > >> will be updated on the next end point after decryption. This would > > >> expect that the next end point must have checksum offload > > >> capability. What if we are capturing the encrypted packets on > > >> wireshark or say send it to some other machine which does not run > > >> DPDK and do not know about > > checksum > > >> offload, then wireshark/other machine will not be able to get the > > >> correct the checksum and will show error. > > > > Understood, we need to have a valid inner checksum. > > RFC1624 states that the computation would be incorrect in > > corner/boundary case. > > I reckon you are basing your incremental update on RFC1141? > > > > Also I think you should take care of endianess and increment the > > checksum with > > host_to_be(0x0100) instead of +1. > > > > >>>> Because we assume that we always forward the packet in both > > >>>> paths, > > we > > >>>> decrement the ttl in both inbound and outbound. > > >>>> You seem to only increment (recalculate) the checksum of the > > >>>> 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 > > >>>> value > > >> update. > > >> [Akhil]If I take care of the ECN then it would mean I need to > > >> calculate the checksum completely, incremental checksum wont give > correct results. > > >> This would surely impact performance. Any suggestion on how should > > >> we take care of ECN update. Should I recalculate the checksum and > > >> send the patch for ECN update? Or do we have a better solution. > > > > If I am understanding the RFCs mentioned above correctly, you should > > be able to do incremental checksum update for any 16bit field/value of > > the IP header. > > I don't see no reason why you couldn't do something like that, except > > that you would have to follow the full equation instead of just adding > > 0x0100, which would be always the case when decrementing TTL. > > > > What do you think? >=20 > Any comments, Akhil? >=20 > Ok.. will send next version soon. Hi Akhil, Are you sending that version soon? It won't make it the RC2, but it may be = merged for RC3. Thanks, Pablo