DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: Gregory Etelson <getelson@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Ajit Khaparde <ajit.khaparde@broadcom.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
	"stable@dpdk.org" <stable@dpdk.org>,
	Xiaoyun Li <xiaoyun.li@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2] app/testpmd: fix TX checksum calculation for tunnel
Date: Thu, 29 Jul 2021 18:02:07 +0200	[thread overview]
Message-ID: <YQLQ/19PIX55sjpQ@platinum> (raw)
In-Reply-To: <BY5PR12MB4834E52FF20500B232799834A5EB9@BY5PR12MB4834.namprd12.prod.outlook.com>

On Thu, Jul 29, 2021 at 10:31:45AM +0000, Gregory Etelson wrote:
> Hello Olivier,
> 
> [:snip:]
> > >
> > > Correct. Inner checksum is offloaded and outer computed in software.
> > 
> > I think this approach is not sane: the value of the outer checksum depends on
> > the inner checksum, so it has to be calculated after. There is a comment in the
> > code about this:
> > 
> >         /* Then process outer headers if any. Note that the software
> >          * checksum will be wrong if one of the inner checksums is
> >          * processed in hardware. */
> >         if (info.is_tunnel == 1) {
> >                 tx_ol_flags |= process_outer_cksums(outer_l3_hdr, &info,
> >                                 tx_offloads,
> >                                 !!(tx_ol_flags & PKT_TX_TCP_SEG));
> >         }
> 
> I agree. That computation order led to error in my case.
> What if the engine could analyze port TX offload options and select 
> processing order according to existing configuration ?

I really think hardware inner checksum + software outer checksum is
broken by design, because outer checksum depends on inner checksum.

> > > Consider this example:
> > > Tunneled packet arrived at port A and being forwarded through port B.
> > > The packet arrived at port A with correct inner checksums - L3 and L4.
> > > Port B TX offloads inner L3 only.
> > >
> > > process_inner_cksums() sets "ipv4_hdr->hdr_checksum = 0;"
> > unconditionally.
> > > Inner L3 checksum value will be restored by port B TX checksum
> > > offload, but when
> > > process_outer_cksums() runs software calculation on outer L4 it will use 0
> > and produce wrong result.
> > >
> > > Therefore, the patch zeros inner checksum values only before actual
> > software calculations.
> > 
> > I better understand your use case, thanks.
> > 
> > However, with your patch, if the inner L4 checksum is wrong when it arrives
> > on port A, I think it will result in a packet with a wrong outer
> > L4 checksum and a correct inner L4 checksum. Is it what you expect?
> > 
> 
> Wrong checksum reflects ongoing issue that must be investigated and fixed.
> I don't expect forwarding engine to fix wrong checksum because it can hide
> a real problem.

Yes and no :)

We should keep in mind that this engine is a demo / test program for
checksum API. A real-world application should detect and drop a packet
with a wrong checksum.

> > I don't argue against the patch itself. What you suggest better matches the
> > offload API than what we have today. Can you please send another version
> > that better explains the use-case?
> > 
> 
> I posted v3 with updated comment.
> 
> > One more suggestion, maybe for later. Currently, the csumonly engine can be
> > configured to do the checksum in sw or in hw. Maybe we could add a "dont-
> > touch" option, to keep the value in the packet. Would it help for your use-
> > case?
> > 
> 
> That's a very good idea.
> Packets can arrive with pre-calculated correct checksums. Keeping these values
> can save processing time.
> 
> [:snip:]
> 
> Regards,
> Gregory

  reply	other threads:[~2021-07-29 16:02 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19  8:33 [dpdk-dev] [PATCH] " Gregory Etelson
2021-07-21  6:42 ` Ori Kam
2021-07-24 11:37 ` Thomas Monjalon
2021-07-24 12:43   ` Gregory Etelson
2021-07-27 13:07 ` [dpdk-dev] [PATCH v2] " Gregory Etelson
2021-07-28  1:31   ` Li, Xiaoyun
2021-07-28  3:45     ` Gregory Etelson
2021-07-28  4:09   ` Ajit Khaparde
2021-07-28  5:07   ` Li, Xiaoyun
2021-07-28 14:12   ` Olivier Matz
2021-07-28 16:07     ` Gregory Etelson
2021-07-29  8:25       ` Olivier Matz
2021-07-29 10:31         ` Gregory Etelson
2021-07-29 16:02           ` Olivier Matz [this message]
2021-07-29  9:39 ` [dpdk-dev] [PATCH v3] " Gregory Etelson
2021-07-29 16:05   ` Olivier Matz
2021-07-29 17:05     ` Gregory Etelson
2021-07-29 17:01 ` [dpdk-dev] [PATCH v4] " Gregory Etelson
2021-07-30  8:39   ` Olivier Matz
2021-07-30 12:04     ` Thomas Monjalon
2021-08-02 11:21       ` Jiang, YuX

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=YQLQ/19PIX55sjpQ@platinum \
    --to=olivier.matz@6wind.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=getelson@nvidia.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=xiaoyun.li@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).