netdev - Re: [RFC] SFQ planned changes

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] [day] [month] [year] [list]

Date:	Wed, 04 Jan 2012 09:17:25 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Dave Taht <dave.taht@...il.com>
Cc:	Michal Kubeček <mkubecek@...e.cz>,
	netdev@...r.kernel.org,
	"John A. Sullivan III" <jsullivan@...nsourcedevel.com>
Subject: Re: [RFC] SFQ planned changes

Le mercredi 04 janvier 2012 à 08:56 +0100, Dave Taht a écrit :

> I find puzzling that my baseline ping time is nearly 3x yours.
> 
> I guess this is the price I pay for a 680mhz box on the other end.
> 

Hmm... maybe... but this seems strange. A ping handler should be a
matter of 1 to 10 us at most. not 100 us.

Checkout on receiver  machine rx coalescing params : ethtool -c eth0

Here : the sender is a normal link (not trunk mode)

# ethtool -c eth3
Coalesce parameters for eth3:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 24
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 48
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 0


And on my 2nd server, receiver of the ping request, (but also 2 switches
are crossed between these machines). This eth2 is part of a bond0
device, and trunk (vlan) activated on this link.

$ ethtool -c eth2
Coalesce parameters for eth2:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 20
rx-frames: 5
rx-usecs-irq: 0
rx-frames-irq: 5

tx-usecs: 72
tx-frames: 53
tx-usecs-irq: 0
tx-frames-irq: 5

So I have a 20us delay at rx time before NIC sends an interrupt to the
Host to 'deliver' the incoming packet.

If I change it to 1 us :

ethtool -C eth2 rx-usecs 1

then pings are even better, but a given load should generate more
interrupts.

# ping 192.168.20.110
PING 192.168.20.110 (192.168.20.110) 56(84) bytes of data.
64 bytes from 192.168.20.110: icmp_req=1 ttl=64 time=0.067 ms
64 bytes from 192.168.20.110: icmp_req=2 ttl=64 time=0.061 ms
64 bytes from 192.168.20.110: icmp_req=3 ttl=64 time=0.064 ms
64 bytes from 192.168.20.110: icmp_req=4 ttl=64 time=0.064 ms
64 bytes from 192.168.20.110: icmp_req=5 ttl=64 time=0.061 ms
64 bytes from 192.168.20.110: icmp_req=6 ttl=64 time=0.061 ms
64 bytes from 192.168.20.110: icmp_req=7 ttl=64 time=0.062 ms
64 bytes from 192.168.20.110: icmp_req=8 ttl=64 time=0.060 ms
64 bytes from 192.168.20.110: icmp_req=9 ttl=64 time=0.062 ms
64 bytes from 192.168.20.110: icmp_req=10 ttl=64 time=0.062 ms
64 bytes from 192.168.20.110: icmp_req=11 ttl=64 time=0.062 ms
64 bytes from 192.168.20.110: icmp_req=12 ttl=64 time=0.062 ms
64 bytes from 192.168.20.110: icmp_req=13 ttl=64 time=0.058 ms
64 bytes from 192.168.20.110: icmp_req=14 ttl=64 time=0.062 ms
64 bytes from 192.168.20.110: icmp_req=15 ttl=64 time=0.063 ms
64 bytes from 192.168.20.110: icmp_req=16 ttl=64 time=0.063 ms
64 bytes from 192.168.20.110: icmp_req=17 ttl=64 time=0.059 ms
64 bytes from 192.168.20.110: icmp_req=18 ttl=64 time=0.062 ms
^C
--- 192.168.20.110 ping statistics ---
18 packets transmitted, 18 received, 0% packet loss, time 16999ms
rtt min/avg/max/mdev = 0.058/0.061/0.067/0.010 ms



--
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