lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 7 Apr 2016 11:32:56 -0700 From: Ben Greear <greearb@...delatech.com> To: Vijay Pandurangan <vijayp@...ayp.ca> Cc: Cong Wang <xiyou.wangcong@...il.com>, netdev <netdev@...r.kernel.org>, Evan Jones <ej@...njones.ca>, Cong Wang <cwang@...pensource.com> Subject: Re: veth regression with "don’t modify ip_summed; doing so treats packets with bad checksums as good." On 04/07/2016 08:11 AM, Vijay Pandurangan wrote: > On Fri, Mar 25, 2016 at 7:46 PM, Ben Greear <greearb@...delatech.com> wrote: >> A real NIC can either do hardware checksums, or it cannot. If it >> cannot, then the host must do it on the CPU for both transmit and >> receive. >> >> Veth is not a real NIC, and it cannot do hardware checksum offloading. >> >> So, we either lie and pretend it does, or we eat massive amounts >> of CPU usage to calculate and check checksums when sending across >> a veth pair. >> > > That's a good point. Does anyone know what the overhead actually is these days? You could try setting up a system with ixgbe or similar, and then manually disable csum offload using ethtool, and see how that performs in comparison to hardware offload? >> But, if I am purposely corrupting a frame destined for veth, then the only >> reason >> I would want the stack to check the checksums is if I were testing my own >> stack's checksum logic, and that seems to be a pretty limited use. > > > In the common case you're 100% right. OTOH, there's something > disconcerting about an abstraction layer lying and behaving > unexpectedly. Most traffic that originates on a machine can have its > checksums safely ignored. Whatever the reason is (maybe, as you say > you're testing checksums – on the other hand maybe there's a bug in > your code somewhere), I really feel like we should try to figure out a > way to ensure that this optimization is at the very least opt-in… I'm fine with allowing a user to force software-csum on veth devices if someone wants to code that up, but forcing sw-csum for local frames on veth devices should be disabled by default. Thanks, Ben -- Ben Greear <greearb@...delatech.com> Candela Technologies Inc http://www.candelatech.com
Powered by blists - more mailing lists