[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250718162945.0c170473@kernel.org>
Date: Fri, 18 Jul 2025 16:29:45 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Tariq Toukan <tariqt@...dia.com>, "Richard Cochran"
<richardcochran@...il.com>, Thomas Gleixner <tglx@...utronix.de>
Cc: Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
<davem@...emloft.net>, Saeed Mahameed <saeedm@...dia.com>, Leon Romanovsky
<leon@...nel.org>, Mark Bloch <mbloch@...dia.com>,
<netdev@...r.kernel.org>, <linux-rdma@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, Carolina Jubran <cjubran@...dia.com>,
Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net-next 0/3] Support exposing raw cycle counters in PTP
and mlx5
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@nvidia.com/
Powered by blists - more mailing lists