Re: hardware time stamps + existing time stamp usage

[Eric Dumazet <dada1@cosmosbay.com>]

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