Re: hardware time stamps + existing time stamp usage

[Oliver Hartkopp <oliver@hartkopp.net>]

Patrick Ohly wrote:
> On Sat, 2008-10-18 at 04:10 -0600, Oliver Hartkopp wrote:
>   
>> Eric Dumazet wrote:
>>     
>>> Oliver Hartkopp a écrit :
>>>       
>>>> 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 ...
>>     
>
> The last time this topic was discussed the initial proposal also was to
> add another time stamp, pretty much for the same reasons. This approach
> was discarded because enlarging a common structure like skb for rather
> obscure ("Objection, your honor!" - "Rejected.") use cases is not
> acceptable.

I don't want to raise dust again but having HW timestamps are also 
interesting for some CAN (Controller Area Network) users.
We had several discussions on the SocketCAN ML on HW timestamps that are 
provided by some CAN controllers or active/intelligent CAN nodes (with 
onboard-CPUs). For me it was not that relevant as stamping the skb in 
the rx-path was always 'accurate enough' for me - but I'm not the CAN 
timestamp expert. Fortunately the HW timestamp was not pushed into 
skb->data (ugh!) but supporting HW timestamps for userspace apps is 
still a wanted feature.

>  A config option doesn't help much either because to be
> useful for distribution users, it would have to be on by default.
>   

Hm - i tried to follow your points in the linked PDF 
(http://www.linuxclustersinstitute.org/conferences/archive/2008/PDF/Ohly_92221.pdf) 
- and from my perspective having a kernel config option looks like an 
appropriate solution here. Either some CAN controllers or HPC clusters 
that would benefit from HW timestamps are IMHO no 'standard use-cases' 
that use 'standard kernels' provided by a 'standard distributor', right?

I assume the system timestamps to be accurate enough for 'standard 
users' so HW timestamps could be a possible candidate for a config 
option - or did i miss anything vital here?

Especially it makes the implementation very clear and without any 
expensive how-to-bitcompress-several-values-into-tstamp approaches.

Regards,
Oliver