trying to set skb->tstamp before netif_rx did not work in tun/tap driver, 2.6.27

trying to set skb->tstamp before netif_rx did not work in tun/tap driver, 2.6.27

[Bill F]

Hi all,
 
I am trying to set the receive timestamp for a packet in the tun/tap device
driver before sending it into the network stack (by calling netif_rx_ni). On the 
application side I'm using recvmsg() to receive the timestamp along with the 
received packet.
 
I expected that any non-zero skb->tstamp I set would be the value my 
application would see when it used recvmsg(), but a corrupted value is 
coming out.
* If I hardcode skb->tstamp.tv64 to x7777777766666666 
        then recvmsg() always gets x011afd371a82fcc0.
* If I hardcode x4de684b100000000, 
        then recvmsg always gets x4f5f96640f2d1608.
* If I set a timestamp that a different process gave to the tun/tap driver
        (this is the goal), then recvmsg gets a corrupted version of that 
        timestamp.
* If I hardcode a zero tstamp, 
        then an accurate timestamp comes out (but not precise enough for my 
        project).
 
The kernel build is 2.6.27.7, the architecture is MIPS, 64bit. Shouldn't this 
work? Do I need to apply any known patches?
 
This arrangement worked last month in a similar setup: an e1000 driver 
setting tstamp before calling netif_receive_skb() in a 2.6.24 kernel and a 
686 architecture, 32 bit.
 
Thanks in advance.
Bill

Re: trying to set skb->tstamp before netif_rx did not work in tun/tap driver, 2.6.27

[Eric Dumazet]

Le vendredi 08 juillet 2011 à 02:33 +0000, Bill F a écrit :
> Hi all,
>  
> I am trying to set the receive timestamp for a packet in the tun/tap device
> driver before sending it into the network stack (by calling netif_rx_ni). On the 
> application side I'm using recvmsg() to receive the timestamp along with the 
> received packet.
>  
> I expected that any non-zero skb->tstamp I set would be the value my 
> application would see when it used recvmsg(), but a corrupted value is 
> coming out.
> * If I hardcode skb->tstamp.tv64 to x7777777766666666 
>         then recvmsg() always gets x011afd371a82fcc0.
> * If I hardcode x4de684b100000000, 
>         then recvmsg always gets x4f5f96640f2d1608.
> * If I set a timestamp that a different process gave to the tun/tap driver
>         (this is the goal), then recvmsg gets a corrupted version of that 
>         timestamp.
> * If I hardcode a zero tstamp, 
>         then an accurate timestamp comes out (but not precise enough for my 
>         project).
>  
> The kernel build is 2.6.27.7, the architecture is MIPS, 64bit. Shouldn't this 
> work? Do I need to apply any known patches?
>  
> This arrangement worked last month in a similar setup: an e1000 driver 
> setting tstamp before calling netif_receive_skb() in a 2.6.24 kernel and a 
> 686 architecture, 32 bit.
>  

You probably are hardcoding too much things ;)

The only portable tv64 value is the zero one.

Check CONFIG_KTIME_SCALAR on your config, and ktime_set()
implementations in include/linux/ktime.h