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 12:10:24 +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:
> Oliver Hartkopp a écrit :
>> Eric Dumazet wrote:
>>> 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.

But at this point you would also need to save the system timestamp into 
the skb for sockets that do not want the hardware timestamp. The device 
driver has no chance to know whether the socket this skb is sent to 
wants hw tstamps or not.

>>>   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.

But this does not help on received packets, right?

>> 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...

IMHO this is the only way to fulfill the given requirements.
Maybe we should introduce a new kernel config option for hw tstamps then ...

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