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

[Carolina Jubran]

On 30/07/2025 2:33, Jacob Keller wrote:
> On 7/18/2025 4:29 PM, 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.
> >
> > Full thread for folks I CCed in:
> > https://lore.kernel.org/all/1752556533-39218-1-git-send-email-tariqt@xxxxxxxxxx/
>
> I agree with Jakub about the need to properly explain the use cases and
> goals in the commit and cover letter. AFAIK there are no current public
> APIs for reporting cycles to userspace, so this really only makes sense
> with something like DPDK. Even the XDP related helpers expect nanosecond
> units now. Its unclear if we will need other parts of the APIs to also
> handle cycles, or if simple ability to get the current cycles is sufficient.
>
> The API also doesn't directly provide a way to query the expected or
> nominal relationship between cycles and clock time.
>
> If you try to just use PTP_SYS_OFFSET_EXTENDED_CYCLES to compare a
> cycles value to a clock value to adjust a timestamp, that requires that
> some other process is keeping CLOCK_REALTIME and the PHC clock
> synchronized. When handled within the driver, the software typically has
> an assumption about the relationship based on expected frequencies.
> Thus, a conversion from cycles to time uses this relationship.
>
> You don't appear to expose that relationship through the API, which
> means you can only infer it either by knowing the device, or by assuming
> CLOCK_REALTIME is already synchronized with the PHC?
>
> I guess userspace could also simply build its own equivalent of the
> struct timecounter using this API.. hmm.

Hi Jacob,

You’re right I’m not trying to reason about the nominal frequency.
The goal is to collect (cycle, system time) pairs and use them to 
correlate raw device timestamps with host time. This doesn’t require the 
PHC to be synchronized to CLOCK_REALTIME, but it does assume the user 
can estimate the drift or nominal frequency from the ioctl data.

I’ll clarify this in v2.

Thanks,
Carolina