From: Akhil Goyal <akhil.goyal@nxp.com>
To: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
"Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: Update checksum while decrementing ttl
Date: Wed, 19 Oct 2016 08:38:13 +0000 [thread overview]
Message-ID: <DB3PR04MB10743C10BC39E6D154FA82DE6D20@DB3PR04MB107.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D8973CA0BD73@IRSMSX108.ger.corp.intel.com>
-----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 <sergio.gonzalez.monroy@intel.com>; Akhil Goyal <akhil.goyal@nxp.com>; dev@dpdk.org
Subject: RE: [PATCH] examples/ipsec-secgw: Update checksum while decrementing 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
> 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?
Any comments, Akhil?
Ok.. will send next version soon.
next prev parent reply other threads:[~2016-10-19 8:38 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-26 16:32 akhil.goyal
2016-09-26 13:28 ` Sergio Gonzalez Monroy
2016-10-05 0:34 ` De Lara Guarch, Pablo
2016-10-05 6:32 ` Akhil Goyal
2016-10-07 20:53 ` De Lara Guarch, Pablo
2016-10-10 12:05 ` Sergio Gonzalez Monroy
2016-10-17 17:05 ` De Lara Guarch, Pablo
2016-10-19 8:38 ` Akhil Goyal [this message]
2016-10-26 2:29 ` De Lara Guarch, Pablo
2016-09-26 16:32 ` [dpdk-dev] [PATCH] app/test: Remove hard coding for nb_queue_pairs in test_cryptodev akhil.goyal
2016-09-26 19:36 ` De Lara Guarch, Pablo
2016-09-29 14:12 ` Trahe, Fiona
2016-09-29 14:25 ` Thomas Monjalon
2016-09-29 14:29 ` De Lara Guarch, Pablo
2016-09-26 16:33 ` [dpdk-dev] [PATCH] test_cryptodev_perf: IV and digest should be stored at a DMAeble address akhil.goyal
2016-10-05 6:40 ` Akhil Goyal
2016-10-05 9:26 ` Kusztal, ArkadiuszX
2016-10-07 11:32 ` Akhil Goyal
2016-10-07 17:06 ` [dpdk-dev] [PATCH v2] " akhil.goyal
2016-10-07 21:36 ` De Lara Guarch, Pablo
2016-10-10 5:22 ` Akhil Goyal
2016-10-10 16:24 ` De Lara Guarch, Pablo
[not found] ` <20161012111629.14126-1-akhil.goyal@nxp.com>
2016-10-12 18:26 ` [dpdk-dev] [PATCH v3] " Trahe, Fiona
2016-10-13 19:35 ` De Lara Guarch, Pablo
2016-09-29 17:18 ` [dpdk-dev] [PATCH v2] app/test: remove hard-coding of crypto num qps Fiona Trahe
2016-10-05 0:49 ` De Lara Guarch, Pablo
2016-10-06 14:55 ` Trahe, Fiona
2016-10-06 17:34 ` [dpdk-dev] [PATCH v3 0/4] remove hard-coding of crypto num qps and cleanup Fiona Trahe
2016-10-07 0:29 ` De Lara Guarch, Pablo
2016-10-07 0:57 ` De Lara Guarch, Pablo
2016-10-06 17:34 ` [dpdk-dev] [PATCH v3 1/4] crypto/aesni_mb: free ring memory on qp release in PMD Fiona Trahe
2016-10-06 17:34 ` [dpdk-dev] [PATCH v3 2/4] app/test: remove pointless for loop Fiona Trahe
2016-10-06 17:34 ` [dpdk-dev] [PATCH v3 3/4] app/test: cleanup unnecessary ring size setup Fiona Trahe
2016-10-06 17:34 ` [dpdk-dev] [PATCH v3 4/4] app/test: remove hard-coding of crypto num qps Fiona Trahe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DB3PR04MB10743C10BC39E6D154FA82DE6D20@DB3PR04MB107.eurprd04.prod.outlook.com \
--to=akhil.goyal@nxp.com \
--cc=dev@dpdk.org \
--cc=pablo.de.lara.guarch@intel.com \
--cc=sergio.gonzalez.monroy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).