Re: [PATCH v3 3/5] net: Let the active time stamping layer be selectable.

[Vladimir Oltean]

Hello Maxime,

On Fri, Mar 24, 2023 at 11:25:41AM +0100, Maxime Chevallier wrote:
> I'd like to point out a series sent a while ago :
> 
> https://lore.kernel.org/netdev/3a14f417-1ae1-9434-5532-4b3387f25d18@xxxxxxxxxx/
> 
> Here, the MAC's timestamping unit can be configured in 2 ways, which
> boils down to either more accurate timestamps, or better accuracy in
> frequency adjustments for the clock.
> 
> The need is to be able to change this mode at runtime, as we can change
> the clock source for the timestamping unit to a very precise-one,
> therefore using the "accurate timestamps mode" working as a
> grand-master, or switching to slave mode, where we would sacrifice a
> little bit the timestamping precision to get better frequency
> precision.
> 
> So, we can consider here that not only the MAC's timestamping unit has
> a non-fixed precision, but if we go through the route a a new API,
> maybe we can also take this case into account, allowing for a bit of
> configuration of the timestamping unit from userspace?

How would you suggest that this API looks like, what would be there to
configure on the timestamping unit? You're not looking for something
specific like "fine vs coarse" to be accepted, I hope?

Perhaps the stmmac is patched to expose 2 PHCs, one for fine mode and
one for coarse mode, and the timestamping PHC selection enables one more
or the other? In other words, if we expressed this stmmac specific thing
in vendor-agnostic terminology that we already understand, would that work?

The ability of a single MAC to register 2 PHCs might be useful for TSN
switches as well. Long story short, sometimes those expose a free
running clock (uncorrectable in offset and frequency), as well as a
correctable one, and they give the option for PTP hardware timestamps to
sample one clock or the other. TSN offloads (tc-taprio, tc-gate etc)
always use the correctable clock, and 802.1AS / gPTP has the option to
use the free running clock. I'm not interested in this personally, but
there were some talks about the value of doing this some time ago, and I
thought it would be worth mentioning it in this context, as something
else that could benefit from a more generic UAPI.

> > Is it plausible that over time, when PTP timestamping matures and,
> > for example, MDIO devices get support for PTP_SYS_OFFSET_EXTENDED
> > (an attempt was here: https://lkml.org/lkml/2019/8/16/638), the
> > relationship between PTP clock qualities changes, and so does the
> > preference change?
> 
> I'm not exactly familiar with PTP_SYS_OFFSET_EXTENDED, but it looks a
> bit similar in purpose to the above-mentionned use-case.

Nope, not similar at all.