netdev - Re: [E1000-devel] [TCP]: TCP_DEFER

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200806190041.52532.denys@visp.net.lb>
Date:	Thu, 19 Jun 2008 00:41:52 +0300
From:	Denys Fedoryshchenko <denys@...p.net.lb>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	David Miller <davem@...emloft.net>, vgusev@...nvz.org,
	e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, rjw@...k.pl, mcmanus@...ksong.com,
	ilpo.jarvinen@...sinki.fi, kuznet@....inr.ac.ru, xemul@...nvz.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [E1000-devel] [TCP]: TCP_DEFER_ACCEPT causes leak sockets

> * Ingo Molnar <mingo@...e.hu> wrote:
> with e1000e i get:
> 
>  64 bytes from europe (10.0.1.15): icmp_seq=1 ttl=64 time=0.212 ms
>  64 bytes from europe (10.0.1.15): icmp_seq=2 ttl=64 time=0.372 ms
>  64 bytes from europe (10.0.1.15): icmp_seq=3 ttl=64 time=0.815 ms
>  64 bytes from europe (10.0.1.15): icmp_seq=4 ttl=64 time=0.961 ms
>  64 bytes from europe (10.0.1.15): icmp_seq=5 ttl=64 time=0.201 ms
>  64 bytes from europe (10.0.1.15): icmp_seq=6 ttl=64 time=0.788 ms
> 
> TCP latencies are fine too - ssh feels snappy again.
> 
> it still does not have nearly as good latencies as say forcedeth though:
> 
>  64 bytes from mercury (10.0.1.13): icmp_seq=1 ttl=64 time=0.076 ms
>  64 bytes from mercury (10.0.1.13): icmp_seq=2 ttl=64 time=0.085 ms
>  64 bytes from mercury (10.0.1.13): icmp_seq=3 ttl=64 time=0.045 ms
>  64 bytes from mercury (10.0.1.13): icmp_seq=4 ttl=64 time=0.053 ms
> 
> that's 10 times better packet latencies.
> 
> and even an ancient Realtek RTL-8139 over 10 megabit Ethernet (!) has 
> better latencies than the e1000e over 1000 megabit:
> 
>  64 bytes from pluto (10.0.1.10): icmp_seq=2 ttl=64 time=0.309 ms
>  64 bytes from pluto (10.0.1.10): icmp_seq=3 ttl=64 time=0.333 ms
>  64 bytes from pluto (10.0.1.10): icmp_seq=4 ttl=64 time=0.329 ms
>  64 bytes from pluto (10.0.1.10): icmp_seq=5 ttl=64 time=0.311 ms
>  64 bytes from pluto (10.0.1.10): icmp_seq=6 ttl=64 time=0.302 ms
> 
> is it done intentionally perhaps? I dont think it makes much sense to 
> delay rx/tx processing on a completely idle box for such a long time.
Idle box, ICH8 chipset, e1000e, latest git.

MegaRouterCore-KARAM ~ # ping 192.168.20.26
PING 192.168.20.26 (192.168.20.26) 56(84) bytes of data.
64 bytes from 192.168.20.26: icmp_seq=1 ttl=64 time=0.109 ms
64 bytes from 192.168.20.26: icmp_seq=2 ttl=64 time=0.134 ms
64 bytes from 192.168.20.26: icmp_seq=3 ttl=64 time=0.120 ms
64 bytes from 192.168.20.26: icmp_seq=4 ttl=64 time=0.117 ms
64 bytes from 192.168.20.26: icmp_seq=5 ttl=64 time=0.117 ms
64 bytes from 192.168.20.26: icmp_seq=6 ttl=64 time=0.113 ms

Disabling interrupt moderation
MegaRouterCore-KARAM ~ # ethtool -C eth0 rx-usecs 0
MegaRouterCore-KARAM ~ # ping 192.168.20.26
PING 192.168.20.26 (192.168.20.26) 56(84) bytes of data.
64 bytes from 192.168.20.26: icmp_seq=1 ttl=64 time=0.072 ms
64 bytes from 192.168.20.26: icmp_seq=2 ttl=64 time=0.091 ms
64 bytes from 192.168.20.26: icmp_seq=3 ttl=64 time=0.066 ms
64 bytes from 192.168.20.26: icmp_seq=4 ttl=64 time=0.065 ms
64 bytes from 192.168.20.26: icmp_seq=5 ttl=64 time=0.077 ms
64 bytes from 192.168.20.26: icmp_seq=6 ttl=64 time=0.073 ms

Maybe try the same?
ethtool -C eth0 rx-usecs 0

-- 
------
Technical Manager
Virtual ISP S.A.L.
Lebanon
--
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