Re: Network performance degradation from 2.6.11.12 to 2.6.16.20

[Thomas Graf <tgraf@suug.ch>]

* David Miller <davem@davemloft.net> 2006-09-18 14:22
> From: Alexey Kuznetsov <kuznet@ms2.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.