lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 18 Oct 2008 09:38:46 +0200
From:	Oliver Hartkopp <>
To:	Eric Dumazet <>
CC:	Patrick Ohly <>,,
	Octavian Purdila <>,
	Stephen Hemminger <>,
	Ingo Oeser <>, Andi Kleen <>,
	"Ronciak, John" <>
Subject: Re: hardware time stamps + existing time stamp usage

Eric Dumazet wrote:
> Interesting stuff :)


> 1) You want hardware TX stamping on all frames sent behalf a given socket
>  Mark a WANT_HARDWARE_TX_STAMP flag at socket level
>   Copy this flag when generating skb for this socket.
>     When transmitting WANT_HARDWARE_TX_STAMP tagged frame to device,
>     dont feed it to dev_queue_xmit_nit() in dev_hard_start_xmit()
>     In NIC driver tx completion, test skb WANT_HARDWARE_TX_STAMP flag.
>     If set, get tstamp from hardware and copy it to skb tstamp,     
> and call dev_queue_xmit_nit() (we might avoid cloning skb there, since
>     nic driver doesnt need it anymore)
>  This flag could also be set at device level, for all sent frames. 
> (tcpdump new option)
> 2) You want hardware RX stamping on a particular device, yet being 
> able to
>   deliver system time to legacy apps, unaware of hardware tstamps.
>   Set a global flag on device, telling linux stack this device feeds 
> hardware stamp.
>   In driver RX completion, set skb tstamp with hardware stamps.
>   Mark a WANT_HARDWARE_RX_STAMP flag at socket level, for PTP 
> applications.
>   In recv(), if current socket is not marked WANT_HARDWARE_RX_STAMP 
> and device has
>   the global flag set, copy system time in tstamp, overrinding 
> hardware tstamp.

Looks good to me. Just one question regarding
'copy system time in tstamp, overrinding hardware tstamp':

When recv() delivers to several sockets there would be probably 
*different* system time values copied and delivered for the *same* skb, 

If so i would tend to fill both (system time and hw timestamp) on driver 
level into the skb and then decide on socket level what to push into 
user space as you suggested above.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists