netdev - Re: hardware time stamps + existing time stamp usage

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <48FCC777.4020506@hartkopp.net>
Date:	Mon, 20 Oct 2008 20:01:27 +0200
From:	Oliver Hartkopp <oliver@...tkopp.net>
To:	Patrick Ohly <patrick.ohly@...el.com>
CC:	Eric Dumazet <dada1@...mosbay.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Octavian Purdila <opurdila@...acom.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	Ingo Oeser <netdev@...eo.de>, Andi Kleen <ak@...ux.intel.com>,
	"Ronciak, John" <john.ronciak@...el.com>
Subject: Re: hardware time stamps + existing time stamp usage

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html