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: <48F9A43A.7070801@cosmosbay.com>
Date:	Sat, 18 Oct 2008 10:54:18 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Oliver Hartkopp <oliver@...tkopp.net>
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

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html