Re: [PATCH net-next v6 3/3] gve: implement PTP gettimex64

[Jacob Keller]

On 5/8/2026 10:43 AM, Jordan Rhee wrote:
> On Thu, May 7, 2026 at 2:23 PM Jacob Keller <jacob.e.keller@xxxxxxxxx> wrote:
>> On 5/7/2026 2:13 PM, Harshitha Ramamurthy wrote:
>>
>> I'm a bit worried about this part, but if I understand, it would only
>> affect the fallback variant anyways since the clock samples are taken in
>> the host in the precise/fast path.
> 
> Good point, the snapshot *is* used in the precise path to interpolate
> system timestamps that occur before the current timekeeping interval.
> This is my understanding of how historical timestamp interpolation
> works (adjust_historical_crosststamp()).
> 
>         <--      total_history_cycles                      -->
>                                <-- partial_history_cycles -->
> -------|------------------+------------------------------------|----------------+---------->
>  cycles (input)
>   snapshot         sample                               cur_interval        now
> -------|------------------+------------------------------------|----------------+---------->
>  ktime (output)
>         <--                      corr_raw                        -->
> 
> At the start of each timekeeping interval, both the current cycle
> count and ktime are recorded. Each interval boundary consists of a
> (cycle count, ktime) pair.
> 
> It computes the ktime corresponding to sampled cycle count as corr_raw
> * partial_history_cycles / total_history_cycles. In other words, it
> scales the distance between the interval boundaries in ktime units by
> the relative position of the sample in the interval computed using the
> cycle counts. It adds or subtracts this value to whichever interval
> boundary is closer to get the absolute ktime.
> 
> How would this be affected by a very old snapshot? The interpolation
> would still work, but it may be less accurate if the clock is not
> stable. To get a sense of the timescales,
>  - the timekeeping interval is typically 4ms (CONFIG_HZ=250).
>  - the AQ command typically takes 60-80us.
>  - there are 2 sources of contention on the mutex (aux task and gettimex64)
>  - worst case retry loop is 100ms (but this should not happen due to
> how the firmware rate limiter has been tuned)
>  - typical clock stability for the relevant cloud server platforms is
> about 10ppm
> 
> The vast majority of the time, the sample should fall in the current
> or previous timekeeping interval, resulting in the most accurate
> interpolation possible.
> 
> In the worst case for retries and contention, the snapshot could be up
> to 200ms before the current timekeeping interval. Assuming clock
> stability of 10ppm, this translates to 10us of drift per 1s, or 2us
> per 200ms. This is still considerably better than the root dispersion
> in the fallback path (81us), so I think it's OK.
> 
Excellent analysis, and yes I agree that its acceptable.

Thanks,
Jake