On Thu, 19 Jan, 2023 21:45:16 -0800 Jakub Kicinski [off-list ref] wrote:

On Thu, 19 Jan 2023 21:22:00 -0800 Rahul Rameshbabu wrote:

quoted

quoted

Hm, so are you saying that:

adjtime(delta):
	clock += delta

but:

adjfreq(delta):  

Did you mean adjphase here?

Yes, sorry

quoted

quoted

	on clock tick & while delta > 0:
		clock += small_value
		delta -= small_value

because from looking at mlx5 driver code its unclear whether the
implementation does a precise but one shot adjustment or gradual
adjustments.  

The pseudo code your drafted is accurate otherwise. The lack of clarity
in our driver comes from leaving the responsibility of that smooth
gradual transition (to keep in sync with the clock frequency while
running) up to the device.

Ah, I see. That makes sense. This is how system clocks react too 
or is it a local PTP invention? I think it may be worth documenting 
in ptp_clock_kernel.h, most driver authors may not understand 
the difference between adjtime and adjphase :(

I think this concept was uniquely proposed for ptp core stack. I do not
think I have seen this explicit differenciation before (but maybe
internal implementations do take a similar approach).

I agree with improving the documentation of adjphase vs adjtime in
ptp_clock_kernel.h

 * @adjphase:  Adjusts the phase offset of the hardware clock.
 *             parameter delta: Desired change in nanoseconds.
 *
 * @adjtime:  Shifts the time of the hardware clock.
 *            parameter delta: Desired change in nanoseconds.

This doesn't really help much in terms of understanding the difference
of adjusting the phase vs shifting the time. The quote from Vincent I
provided in my previous email was in response to a question raised by
Aya Levin who was working on timing related features in the mlx5 driver.

https://lore.kernel.org/netdev/228ceba4-47a8-49ef-994a-fe898cdc7fc1@nvidia.com/ (local)