no worries ont that side, In my code timeStamp is a "struct timeval".
2007/11/13, Antoine Zen-Ruffinen <antoine.zen@xxxxxxxxx>:
> 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 <dada1@xxxxxxxxxxxxx>:
> > 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 netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
