no worries ont that side, In my code timeStamp is a "struct timeval".
2007/11/13, Antoine Zen-Ruffinen <[EMAIL PROTECTED]>: > This is exactly my problem : The driver of the network card I am using > (see rt2x00.serialmonkey.com) do the minimum in the hardware interrupt > (not filling skb->tstamp). Then netif_rx() is called later using a > tasklet (also not filling skb->tstamp). As it seem to me (maybe I am > wrong, if so please tell), the elapse time between the actual frame > arrival and the time where netif_rx() do net_timestamp(skb) is not > predicable !? > > Else, I would like to thank you to spend time helping me. > > > > 2007/11/13, Eric Dumazet <[EMAIL PROTECTED]>: > > Antoine Zen-Ruffinen a écrit : > > > What does it bring me to have a nanosecond precision if it is not > > > related to the actual arrival of frame time ? As it seem I can feel > > > skb->tstamp with whatever I want, I always become something else using > > > ioctl(). (I'm using kernel 2.6.23). > > > > > > > > I guess you misunderstood kernel source, because it is related to > > arrival time, more exactly when it was processed by network stack. > > (Beware modern NICS can delay the rx interrupt by some us (ethtool -c > > eth0), so that an interrupt can feed more than one packet to the OS) > > > > Check net/core/dev.c function netif_rx() > > > > { > > ... > > if (!skb->tstamp.tv64) > > net_timestamp(skb); > > > > } > > > > So as soon your system as at least one socket 'asking for tsamps', > > netstamp_needed is not null, and net_timestamp() will call __net_timestamp() > > wich does : > > > > skb->tstamp = ktime_get_real(); > > > > So you should not 'feed' tstamp.tv64 and let it being 0, so that > > netif_rx() can do its job. > > > > > > > > > > > > > - 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