linux-kernel - Re: Network performance degradation from 2.6.11.12 to 2.6.16.20

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]

Date:	Tue, 19 Sep 2006 22:31:05 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	David Miller <davem@...emloft.net>
Cc:	kuznet@....inr.ac.ru, ak@...e.de, master@...torb.msk.ru,
	hawk@...u.dk, harry@...os.washington.edu,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Network performance degradation from 2.6.11.12 to 2.6.16.20

* David Miller <davem@...emloft.net> 2006-09-18 14:22
> From: Alexey Kuznetsov <kuznet@....inr.ac.ru>
> Date: Tue, 19 Sep 2006 01:03:21 +0400
> 
> > 1. It even does not disable possibility to record timestamp inside
> >    driver, which Alan was afraid of. The sequence is:
> > 
> > 	if (!skb->tstamp.off_sec)
> >                 net_timestamp(skb);
> > 
> > 2. Maybe, netif_rx() should continue to get timestamp in netif_rx().
> > 
> > 3. NAPI already introduced almost the same inaccuracy. And it is really
> >    silly to waste time getting timestamp in netif_receive_skb() a few
> >    moments before the packet is delivered to a socket.
> > 
> > 4. ...but clock source, which takes one of top lines in profiles
> >    must be repaired yet. :-)
> 
> Ok, ok, but don't we have queueing disciplines that need the timestamp
> even on ingress?

Queueing disciplines generally only care about the time delta
between two packets, using the receive stamp would lead to
wrong results as soon as a packet is queued more than once.

However, since we recently introcued ingress queueing we
must update the stamp to make up for the delay caused by the
queue. Updating the stamp at socket enqueue time would solve
this automatically.

It seems only natural to me that the real problem is the slow
clock source which needs to be resolved regardless of the
outcome of this discussion. I believe that updating the stamp
at socket enqueue time is the right thing to do but it shouldn't
be considered as a solution to the performance problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/