Re: [PATCH RFC V1 net-next 3/4] net: Let the active time stamping layer be selectable.

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Mon, Jan 24, 2022 at 07:37:16AM -0800, Richard Cochran wrote:
> On Mon, Jan 24, 2022 at 10:28:23AM +0100, Miroslav Lichvar wrote:
> 
> > FWIW, scm_timestamping has three fields and the middle one no longer
> > seems to be used. If a new socket/timestamping option enabled all
> > three (SW, MAC, PHY) timestamps in the cmsg, I think that would be a
> > nice feature.
> 
> This won't work because:
> 
> - There would need to be seven^W eight, not three slots.
> 
> - Even with just three, the CMSG would have to have a bit that clearly
>   identifies the new format.
>  
> > From an admin point of view, it makes sense to me to have an option to
> > disable PHY timestamps for the whole device if there are issues with
> > it. For debugging and applications, it would be nice to have an option
> > to get all of them at the same time.
> 
> Right.  Those are two different use cases.  The present series
> addresses the first one.  The second one entails making a new flavor
> of time stamping API.

I agree that they are different use cases, but with the runtime PHC
change being now possible, there isn't really a clear-cut moment when an
application can now say "from this moment on, I'm only getting
timestamps from the new PHC". Especially when you switch over from the
PHY to the MAC, a few tens of ms may pass until you get an RX timestamp
from the PHY, and the MAC PHC may well be up and operational in the
meantime, and ptp4l synchronizing based on its timestamps.

I don't have a clear idea how to put it in practice, either. I'll think
about it, but the problem I see is that the phc_index reported by
"ethtool -T" becomes a fuzzy concept in the presence of multiple PHCs.
Adding the ability to retrieve timestamps from all of them doesn't make
it any easier to select which one gets reported to ethtool.
Maybe there's room for both the sysfs and the socket option after all.