Re: hardware time stamps + existing time stamp usage

[Oliver Hartkopp <oliver@hartkopp.net>]

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