Re: hardware time stamps + existing time stamp usage

[Oliver Hartkopp <oliver@hartkopp.net>]

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?

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.

Regards,
Oliver