Re: [PATCH net-next v3] net: micrel: Change to receive timestamp in the frame for lan8841

[Richard Cochran <richardcochran@gmail.com>]

On Tue, Jun 20, 2023 at 11:30:21AM -0700, Jakub Kicinski wrote:
> Richard, looks good?

Yes.
 
> I'm not sure if the settime handling is sufficient, some packets may
> still sneak thru both getting stamped with new value of time and use
> old upper bits and get stamped with old bits and use new upper.
> Can we disable timestamping, drain the queue, then change the time
> and enable stamping again?

This can happen with any driver.  The user space stack combines four
time stamps to calculate the PTP client/server offset.  When setting
the clock, some skbs might be in the kernel's Rx path with the "old"
timestamp.

The kernel doesn't track Rx skbs that have HW timestamps, and stopping
the MAC and then flushing _everything_ seems heavy handed to me.

In the user space PTP stack, setting the clock happens immediately
after Sync message reception.  For configurations with a very high
Sync rate, a linuxptp client has an option to skip a given number of
messages after setting the clock.  In this way you can avoid stale
timestamps by choosing a duration that is longer than the longest
frame residence time from MAC to kernel.

Thanks,
Richard