| 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: Wed, 09 Jul 2014 00:44:35 +0200 From: Eric Dumazet <eric.dumazet@...il.com> To: Wolfgang Walter <linux@...m.de> Cc: netdev <netdev@...r.kernel.org>, Jerry Chu <hkchu@...gle.com> Subject: Re: GRO: very bad routing performance with 3.14.4 for GRE-packets On Tue, 2014-07-08 at 22:35 +0200, Wolfgang Walter wrote: > Hello, > > I upgraded a router from 3.10.46 to 3.14.4 and I see a dramatic perfomance > loss for GRE-pakets if (and only if) GRO is enabled on the incoming or > outgoing interface (drops to 1/50th to 1/100th). > > Other traffic is just fine. > > The router itself is not endpoint of the GRE-tunnel. > > The router has connection tracking enabled and does NAT (but most of the > traffic is not NATed nor are GRE-packets). > > The network card is an Intel Corporation I350 Gigabit (both interfaces). > > Regards, GRO is a win if the consumer of the packets understands GSO packets. In this case, Intel driver is not able to send GSO packets with GRE encapsulation, so they need to be segmented before being sent. That's extra work and not worth it, as you noticed. One way to get good performance would be to implement a software TSO in the Intel driver for the GRE encapsulated packets. You might revert bf5a755f5e9186406bbf50f4087100af5bd68e40, or submit a patch to make the GRE handling in GRO an optional feature. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists