Re: [PATCH net-next 0/3] Support exposing raw cycle counters in PTP and mlx5

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, Jul 18 2025 at 16:29, Jakub Kicinski wrote:
> On Tue, 15 Jul 2025 08:15:30 +0300 Tariq Toukan wrote:
>> 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