* David Miller <[EMAIL PROTECTED]> 2006-09-18 14:22 > From: Alexey Kuznetsov <[EMAIL PROTECTED]> > 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 netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
