From mboxrd@z Thu Jan 1 00:00:00 1970 From: "De Lara Guarch, Pablo" Subject: Re: [PATCH] examples/ipsec-secgw: Update checksum while decrementing ttl Date: Mon, 17 Oct 2016 17:05:17 +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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To: "Gonzalez Monroy, Sergio" , Akhil Goyal , "dev@dpdk.org" Return-path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id D5BA22BA9 for ; Mon, 17 Oct 2016 19:05:20 +0200 (CEST) In-Reply-To: <73f643bf-9ca8-f38a-fbfb-5a127d9d01b5@intel.com> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----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 >=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 > >> 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 her= e > >> 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 a= re > >> 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. >=20 > 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? >=20 > Also I think you should take care of endianess and increment the > checksum with > host_to_be(0x0100) instead of +1. >=20 > >>>> 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 I= P > >>>> 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 calculat= e > >> the checksum completely, incremental checksum wont give correct result= s. > >> This would surely impact performance. Any suggestion on how should we > >> take care of ECN update. Should I recalculate the checksum and send th= e > >> patch for ECN update? Or do we have a better solution. >=20 > 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. >=20 > What do you think? Any comments, Akhil?