On Fri, Jul 18 2025 at 16:29, Jakub Kicinski wrote:

On Tue, 15 Jul 2025 08:15:30 +0300 Tariq Toukan wrote:

quoted

This patch series introduces support for exposing the raw free-running
cycle counter of PTP hardware clocks. Some telemetry and low-level
logging use cycle counter timestamps rather than nanoseconds.
Currently, there is no generic interface to correlate these raw values
with system time.

To address this, the series introduces two new ioctl commands that
allow userspace to query the device's raw cycle counter together with
host time:

 - PTP_SYS_OFFSET_PRECISE_CYCLES

 - PTP_SYS_OFFSET_EXTENDED_CYCLES

These commands work like their existing counterparts but return the
device timestamp in cycle units instead of real-time nanoseconds.

This can also be useful in the XDP fast path: if a driver inserts the
raw cycle value into metadata instead of a real-time timestamp, it can
avoid the overhead of converting cycles to time in the kernel. Then
userspace can resolve the cycle-to-time mapping using this ioctl when
needed.

Adds the new PTP ioctls and integrates support in ptp_ioctl():
- ptp: Add ioctl commands to expose raw cycle counter values

Support for exposing raw cycles in mlx5:
- net/mlx5: Extract MTCTR register read logic into helper function
- net/mlx5: Support getcyclesx and getcrosscycles

It'd be great to an Ack from Thomas or Richard on this (or failing that
at least other vendors?) Seems like we have a number of parallel
efforts to extend the PTP uAPI, I'm not sure how they all square
against each other, TBH.

I don't see a conflict vs. the aux clock support. These are orthogonal
issues and from a conceptual point it makes sense to me to expose the
raw cycles for the purposes Tariq described.

Thanks,

        tglx