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 10:54:18 +0200
From:	Eric Dumazet <>
To:	Oliver Hartkopp <>
Cc:	Patrick Ohly <>,,
	Octavian Purdila <>,
	Stephen Hemminger <>,
	Ingo Oeser <>, Andi Kleen <>,
	"Ronciak, John" <>
Subject: Re: hardware time stamps + existing time stamp usage

Oliver Hartkopp a écrit :
> Eric Dumazet wrote:
>> Interesting stuff :)
> Indeed.
>> 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, 
> right?

As we introduced a new skb flag for the TX part, we could reuse it in order
to copy system time to tstamp only once for the RX part.
> 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.

Well, this would enlarge skb structure by 8 bytes, since you cannot use
same tstamp location to fille both 8 bytes values.
This is probably the easy way, but very expensive...

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