Re: [PATCH RFC net-next v8 04/13] net: Change the API of PHY default timestamp to MAC

[Andrew Lunn <andrew@lunn.ch>]

On Fri, Feb 16, 2024 at 10:09:36AM -0800, Rahul Rameshbabu wrote:
> 
> On Fri, 16 Feb, 2024 16:52:22 +0100 Kory Maincent <kory.maincent@bootlin.com> wrote:
> > Change the API to select MAC default time stamping instead of the PHY.
> > Indeed the PHY is closer to the wire therefore theoretically it has less
> > delay than the MAC timestamping but the reality is different. Due to lower
> > time stamping clock frequency, latency in the MDIO bus and no PHC hardware
> > synchronization between different PHY, the PHY PTP is often less precise
> > than the MAC. The exception is for PHY designed specially for PTP case but
> > these devices are not very widespread. For not breaking the compatibility
> > default_timestamp flag has been introduced in phy_device that is set by
> > the phy driver to know we are using the old API behavior.
> >
> > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> > ---
> 
> Overall, I agree with the motivation and reasoning behind the patch. It
> takes dedicated effort to build a good phy timestamping mechanism, so
> this approach is good. I do have a question though. In this patch if we
> set the phy as the default timestamp mechanism, does that mean for even
> non-PTP applications, the phy will be used for timestamping when
> hardware timestamping is enabled? If so, I think this might need some
> thought because there are timing applications in general when a
> timestamp closest to the MAC layer would be best.

Could you give some examples? It seems odd to me, the application
wants a less accurate timestamp?

Is it more about overheads? A MAC timestamp might be less costly than
a PHY timestamp?

Or is the application not actually doing PTP, it does not care about
the time of the packet on the wire, but it is more about media access
control? Maybe the applications you are talking about are misusing the
PTP API for something its not intended?

    Andrew