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
| ||
|
Message-ID: <20121229210713.GA4350@paralelels.com> Date: Sun, 30 Dec 2012 01:07:14 +0400 From: Andrew Vagin <avagin@...allels.com> To: Eric Dumazet <eric.dumazet@...il.com> CC: <netdev@...r.kernel.org>, <vvs@...allels.com>, Michał Mirosław <mirq-linux@...e.qmqm.pl> Subject: Re: Slow speed of tcp connections in a network namespace On Sat, Dec 29, 2012 at 12:20:07PM -0800, Eric Dumazet wrote: > On Sun, 2012-12-30 at 00:08 +0400, Andrew Vagin wrote: > > On Sat, Dec 29, 2012 at 11:41:02AM -0800, Eric Dumazet wrote: > > > On Sat, 2012-12-29 at 19:58 +0100, Eric Dumazet wrote: > > > > Le samedi 29 décembre 2012 à 09:40 -0800, Eric Dumazet a écrit : > > > > > > > > > > > > > > Please post your new tcpdump then ;) > > > > > > > > > > also post "netstat -s" from root and test ns after your wgets > > > > > > > > Also try following bnx2 patch. > > > > > > > > It should help GRO / TCP coalesce > > > > > > > > bnx2 should be the last driver not using skb head_frag > > > > I don't have access to the host. I'm going to test your patch tomorrow. > > Thanks. > > > > > > > > And of course, you should make sure all your bnx2 interrupts are handled > > > by the same cpu. > > All bnx interrupts are handled on all cpus. They are handled on the same > > cpu, if a kernel is booted with msi_disable=1. > > > > Is it right, that a received window will be less, if packets are not sorted? > > Looks like a bug. > > > > I want to say, that probably it works correctly, if packets are sorted. > > But I think if packets are not sorted, it should work with the same > > speed, cpu load and memory consumption may be a bit more. > > Without veth, it doesnt really matter that IRQ are spread on multiple > cpus, because packets are handled in NAPI, and only one cpu runs the > eth0 NAPI handler at one time. > > But as soon as packets are queued (by netif_rx()) for 'later' > processing, you can have dramatic performance decrease. > > Thats why you really should make sure IRQ on your eth0 device > are handled by a single cpu. > > It will help to get better performance in most cases. I understand this fact, but so big difference looks strange for me. Default configuration (with the bug): # cat /proc/interrupts | grep eth0 68: 10187 10188 10187 10023 10190 10185 10187 10019 PCI-MSI-edge eth0 > > echo 1 >/proc/irq/*/eth0/../smp_affinity This doesn't help. I tryed echo 0 > /proc/irq/68/smp_affinity_list. This doesn't help too. > > If it doesnt work, you might try instead : > > echo 1 >/proc/irq/default_smp_affinity > <you might need to reload bnx2 module, or ifdown/ifup eth0 > This helps, and the bug are not reproduced in this case. # cat /proc/interrupts | grep eth0 68: 60777 0 0 0 0 0 0 0 PCI-MSI-edge eth0 Thanks. -- 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