On Tue, 29 Jul 2025 09:57:13 +0300 Carolina Jubran wrote:

One concrete use case is monitoring the frequency stability of the 
device clock in FreeRunning mode. User space can periodically sample the 
(cycle, time) pairs returned by the new ioctl to estimate the clock’s 
frequency and detect anomalies, for example, drift caused by temperature 
changes. This is especially useful in holdover scenarios.

Because the servo running on the host doesn't know the stability?
Seems like your real use case is the one below.

Another practical case is with DPDK. When the hardware is in FreeRunning 
mode, the CQE contains raw cycle counter values. DPDK returns these 
values directly to user space without converting them. The new ioctl 
provides a generic and consistent way to translate those raw values to 
host time.

As for XDP, you’re right that it doesn’t expose raw cycles today. The 
point here is more future-looking: if drivers ever choose to emit raw 
cycles into metadata for performance, this API gives user space a clean 
way to interpret those timestamps.

Got it, I can see how DPDK / kernel bypass may need this.

Please include this justification in the commit message for v2 
and let's see if anyone merges it.