DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>, <dev@dpdk.org>
Cc: "Olivier Matz" <olivier.matz@6wind.com>,
	"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"Jerin Jacob Kollanukkaran" <jerinj@marvell.com>,
	"Ferruh Yigit" <ferruh.yigit@amd.com>,
	"Thomas Monjalon" <thomas@monjalon.net>,
	"David Marchand" <david.marchand@redhat.com>
Subject: RE: Is it correct to report checksum good when there is no checksum?
Date: Thu, 10 Nov 2022 10:55:14 +0100	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D874AA@smartserver.smartshare.dk> (raw)
In-Reply-To: <8bea1ef1-1977-f24f-f549-0c2126c23e3c@oktetlabs.ru>

> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
> Sent: Thursday, 10 November 2022 10.26
> 
> Hi all,
> 
> some drivers report RTE_MBUF_F_RX_IP_CKSUM_GOOD for IPv6 packets.
> For me it looks strange, but I see some technical reasons behind.

Please note: IPv6 packets by definition have no IP checksum.

> Documentation in lib/mbuf/rte_mbuf_core.h is a bit vague.
> Should UNKNOWN or NONE be used instead?

Certainly not NONE. Its description says: "the IP checksum is *not* correct in the packet [...]". But there is no incorrect IP checksum in the packet.

I will argue against UNKNOWN. Its description says: "no information about the RX IP checksum". But we do have information about it! We know that the IP checksum is not there (the value is "NULL"), and that it is not supposed to be there (the value is supposed to be "NULL").

So I consider GOOD the correct response here.

GOOD also means that the application can proceed processing the packet normally without further IP header checksum checking, so it's good for performance.

It should be added to the description of RTE_MBUF_F_RX_IP_CKSUM_GOOD that IPv6 packets always return this value, because IPv6 packets have no IP header checksum, and that is what is expected of them.

-Morten


  reply	other threads:[~2022-11-10  9:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-10  9:25 Is it correct to report checksum good when there is no checksum? Andrew Rybchenko
2022-11-10  9:55 ` Morten Brørup [this message]
2022-11-10 10:08   ` Andrew Rybchenko
2022-11-10 10:29     ` Thomas Monjalon
2022-11-10 10:29     ` Morten Brørup
2022-11-10 10:34       ` Andrew Rybchenko
2022-11-10 11:02         ` Morten Brørup
2022-11-10 11:11           ` Bruce Richardson
2022-11-10 11:26             ` Andrew Rybchenko
2022-11-10 11:57               ` Morten Brørup
2022-11-10 11:23           ` Andrew Rybchenko

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=98CBD80474FA8B44BF855DF32C47DC35D874AA@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=jerinj@marvell.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /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