Re: [PATCH net-next v6 4/7] net: dsa: hellcreek: Add support for hardware timestamping

On Tue Oct 06 2020, Vladimir Oltean wrote:

On Tue, Oct 06, 2020 at 03:56:31PM +0200, Kurt Kanzenbach wrote:

quoted

On Tue Oct 06 2020, Vladimir Oltean wrote:

quoted

On Tue, Oct 06, 2020 at 03:30:36PM +0200, Kurt Kanzenbach wrote:

quoted

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