On 30/07/2025 1:40, Jakub Kicinski wrote:

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

quoted

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.

quoted

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.

Thanks, I’ll include the DPDK/kernel bypass justification clearly in the 
v2 commit message and cover letter.

Additionally, I wanted to mention another relevant use case that wasn’t 
brought up earlier: fwctl can expose event records tagged with raw cycle 
counter timestamps. When the device is in free-running mode, correlating 
those with host time becomes difficult unless user space has access to 
both cycle and system time snapshots.