[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1462043884.17662.7.camel@decadent.org.uk>
Date: Sat, 30 Apr 2016 21:18:04 +0200
From: Ben Hutchings <ben@...adent.org.uk>
To: Ben Greear <greearb@...delatech.com>,
Sabrina Dubroca <sd@...asysnail.net>
Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
akpm@...ux-foundation.org, "David S. Miller" <davem@...emloft.net>,
Vijay Pandurangan <vijayp@...ayp.ca>,
Cong Wang <cwang@...pensource.com>, netdev@...r.kernel.org,
Evan Jones <ej@...njones.ca>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
Phil Sutter <phil@....cc>,
Toshiaki Makita <makita.toshiaki@....ntt.co.jp>,
xiyou.wangcong@...il.com
Subject: Re: [PATCH 3.2 085/115] veth: don’t modify
ip_summed; doing so treats packets with bad checksums as good.
On Thu, 2016-04-28 at 06:45 -0700, Ben Greear wrote:
>
> On 04/28/2016 03:29 AM, Sabrina Dubroca wrote:
[...]
> > Your use case is invalid, it just happened to work because of a
> > bug. If you want the stack to fill checksums so that you want capture
> > and reinject packets, you have to disable checksum offloading (or
> > compute the checksum yourself in userspace).
> Disabling checksum offloading or computing in user-space (and then
> recomputing in veth to verify the checksum?) is a huge performance loss.
>
> Maybe we could add a socket option to enable Cong's patch on a per-socket
> basis? That way my use-case can still work and you can have this new
> behaviour by default?
It does sound like a useful option to have. If there are other
applications that depend on veth's checksum-fixing behaviour and are
being distributed in binary form, then a per-device option might be
necessary so users can keep those applications working before they're
updated.
Ben.
--
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists