From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
To: "Morten Brørup" <mb@smartsharesystems.com>, dev@dpdk.org
Cc: Olivier Matz <olivier.matz@6wind.com>,
Konstantin Ananyev <konstantin.ananyev@huawei.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 13:34:24 +0300 [thread overview]
Message-ID: <aef21fe2-e494-6554-18bc-8475fbf4be5c@oktetlabs.ru> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D874AC@smartserver.smartshare.dk>
On 11/10/22 13:29, Morten Brørup wrote:
>> From: Andrew Rybchenko [mailto:andrew.rybchenko@oktetlabs.ru]
>> Sent: Thursday, 10 November 2022 11.09
>>
>> On 11/10/22 12:55, Morten Brørup wrote:
>>>> 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.
>>>
>>
>> Thanks, I should read the definition of none more careful.
>>
>>> 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").
>>>
>>
>> I thought that "no checksum" => "no information" => UNKNOWN
>
> That was my initial interpretation too, and it stuck with me for a while.
>
> But then I tried hard to read it differently, tweaking it to support the conclusion I was looking for.
>
>>
>>> 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 is very important point and would be nice to have in GOOD
>> case definition (both IP and L4 cases). It is the right
>> motivation why GOOD makes sense for IPv6.
>>
>>> 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.
>>>
>>
>> Could you make a patch?
>
> Too busy right now, but I'll put it on my todo list. :-)
>
>>
>> Bonus question is UDP checksum 0 case. GOOD as well?
>> (just want to clarify the documentation while we're on it).
>
> No. The UDP checksum is not optional in IPv6.
>
> RFC 2460 section 8.1 bullet 4 says: "Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. [...] IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error."
>
Yes I know, but I'm asking about IPv4 case with UDP checksum 0.
next prev parent reply other threads:[~2022-11-10 10:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 9:25 Andrew Rybchenko
2022-11-10 9:55 ` Morten Brørup
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 [this message]
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=aef21fe2-e494-6554-18bc-8475fbf4be5c@oktetlabs.ru \
--to=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@huawei.com \
--cc=mb@smartsharesystems.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;
as well as URLs for NNTP newsgroup(s).