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: <48F9B610.2090504@hartkopp.net>
Date:	Sat, 18 Oct 2008 12:10:24 +0200
From:	Oliver Hartkopp <oliver@...tkopp.net>
To:	Eric Dumazet <dada1@...mosbay.com>
CC:	Patrick Ohly <patrick.ohly@...el.com>, 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

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

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