From: Edward Cree <ecree@solarflare.com>
To: Tom Herbert <tom@herbertland.com>, Jesse Gross <jesse@kernel.org>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>,
<linux-net-drivers@solarflare.com>
Subject: Re: [PATCH v2 net-next 3/5] net: vxlan: enable local checksum offload
Date: Mon, 11 Jan 2016 18:27:09 +0000 [thread overview]
Message-ID: <5693F3FD.4030804@solarflare.com> (raw)
In-Reply-To: <CALx6S35sBDydNEmJwcBfKnbVhFdtEk8dkwjWsVRhrEHOLn4jTQ@mail.gmail.com>
On 11/01/16 17:55, Tom Herbert wrote:
> On Mon, Jan 11, 2016 at 9:24 AM, Jesse Gross <jesse@kernel.org> wrote:
>> It's hard to say what other types of endpoints might do if they
>> receive a VXLAN packet with a checksum set and, of course, there are
>> other protocols that don't specify that received UDP checksums can be
>> ignored.
>>
> RFC1122 is very clear on the subject of UDP checksums:
>
> "If a UDP datagram is received with a checksum that is non- zero and
> invalid, UDP MUST silently discard the datagram."
>
> So if a VXLAN receiver accepts a UDP packet without checking a
> non-zero UDP checksum for validity they are breaking the UDP protocol.
> If they blow up because they don't expect to receive non-zero
> checksums that is entirely their problem.
More to the point, RFC7348 says that if the outer checksum isvalid, the
receiver MUST accept it.
"If the decapsulating destination chooses not to perform the verification,
or performs it successfully, the packet MUST be accepted for decapsulation."
Therefore, if they blow up because they don't expect to receive non-zero
checksums, they're not compliant with the spec.
On the other hand, there is always 'be conservative in what you emit'... how
far should you go to interoperate with broken implementations.
On the gripping hand, I suspect RFC7348 only recommends against outer csums
in the first place because the authors believed it was expensive.
-ed
next prev parent reply other threads:[~2016-01-11 18:27 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 17:10 [PATCH v2 net-next 0/5] Local Checksum Offload Edward Cree
2016-01-07 17:12 ` [PATCH v2 net-next 1/5] net: local checksum offload for encapsulation Edward Cree
2016-01-07 17:22 ` David Laight
2016-01-07 17:54 ` Edward Cree
2016-01-07 18:42 ` Tom Herbert
2016-01-07 22:53 ` Alexander Duyck
2016-01-08 15:32 ` Edward Cree
2016-01-08 17:30 ` Alexander Duyck
2016-01-07 17:12 ` [PATCH v2 net-next 2/5] net: enable LCO for udp_tunnel_handle_offloads() users Edward Cree
2016-01-07 17:12 ` [PATCH v2 net-next 3/5] net: vxlan: enable local checksum offload Edward Cree
2016-01-08 0:15 ` Alexander Duyck
2016-01-08 15:33 ` Edward Cree
2016-01-08 3:46 ` Alexander Duyck
2016-01-08 15:39 ` Edward Cree
2016-01-08 18:03 ` Alexander Duyck
2016-01-08 19:40 ` Jesse Gross
2016-01-08 21:22 ` Alexander Duyck
2016-01-08 21:36 ` Rick Jones
2016-01-08 22:07 ` Tom Herbert
2016-01-11 17:24 ` Jesse Gross
2016-01-11 17:55 ` Tom Herbert
2016-01-11 18:27 ` Edward Cree [this message]
2016-01-11 18:43 ` Tom Herbert
2016-01-07 17:13 ` [PATCH v2 net-next 4/5] fou: enable LCO in FOU and GUE Edward Cree
2016-01-07 18:51 ` Tom Herbert
2016-01-07 19:00 ` Edward Cree
2016-01-07 17:14 ` [PATCH v2 net-next 5/5] Documentation/networking: add tx-offloads.txt to explain LCO Edward Cree
2016-01-07 18:58 ` Tom Herbert
2016-01-11 17:05 ` [RFC PATCH 0/2] Rework of "net: local checksum offload for encapsulation" Alexander Duyck
2016-01-11 17:06 ` [RFC PATCH 1/2] net: local checksum offload for encapsulation Alexander Duyck
2016-01-11 17:06 ` [RFC PATCH 2/2] net: Add support for UDP local checksum offload as a part of tunnel segmentation Alexander Duyck
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=5693F3FD.4030804@solarflare.com \
--to=ecree@solarflare.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=jesse@kernel.org \
--cc=linux-net-drivers@solarflare.com \
--cc=netdev@vger.kernel.org \
--cc=tom@herbertland.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.