On Tue Oct 06 2020, Vladimir Oltean wrote:
> On Tue, Oct 06, 2020 at 03:56:31PM +0200, Kurt Kanzenbach wrote:
>> On Tue Oct 06 2020, Vladimir Oltean wrote:
>> > On Tue, Oct 06, 2020 at 03:30:36PM +0200, Kurt Kanzenbach wrote:
>> >> That's the point. The user (or anybody else) cannot disable hardware
>> >> stamping, because it is always performed. So, why should it be allowed
>> >> to disable it even when it cannot be disabled?
>> >
>> > Because your driver's user can attach a PTP PHY to your switch port, and
>> > the network stack doesn't support multiple TX timestamps attached to the
>> > same skb. They'll want the TX timestamp from the PHY and not from your
>> > switch.
>> 
>> Yeah, sure. That use case makes sense. What's the problem exactly?
>
> The SO_TIMESTAMPING / SO_TIMESTAMPNS cmsg socket API simply doesn't have
> any sort of identification for a hardware TX timestamp (where it came
> from).

This is sounds like a problem. For instance the hellcreek switch has
actually three ptp hardware clocks and the time stamping can be
configured to use either one of them. How would the user space
distinguish what time stamp is taken by which clock? This is not a
problem at the moment, because currently only the synchronized clock is
exported to user space. See change log of this patch.

> So when you'll poll for TX timestamps, you'll receive a TX
> timestamp from the PHY and another one from the switch, and those will
> be in a race with one another, so you won't know which one is which.

OK. So what happens if the driver will accept to disable hardware
timestamping? Is there anything else that needs to be implemented? Are
there (good) examples?

Thanks,
Kurt