[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bbd6a75b644bf11b82af7fa25a47e4fa20630958.camel@redhat.com>
Date: Tue, 07 May 2024 10:42:35 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Mahesh Bandewar <maheshb@...gle.com>, Netdev <netdev@...r.kernel.org>,
Linux <linux-kernel@...r.kernel.org>, David Miller <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>, Richard Cochran
<richardcochran@...il.com>, Arnd Bergmann <arnd@...db.de>, Sagi Maimon
<maimon.sagi@...il.com>
Cc: Jonathan Corbet <corbet@....net>, John Stultz <jstultz@...gle.com>,
Mahesh Bandewar <mahesh@...dewar.net>
Subject: Re: [PATCHv4 net-next] ptp/ioctl: support MONOTONIC_RAW timestamps
for PTP_SYS_OFFSET_EXTENDED
On Thu, 2024-05-02 at 14:10 -0700, Mahesh Bandewar wrote:
> The ability to read the PHC (Physical Hardware Clock) alongside
> multiple system clocks is currently dependent on the specific
> hardware architecture. This limitation restricts the use of
> PTP_SYS_OFFSET_PRECISE to certain hardware configurations.
>
> The generic soultion which would work across all architectures
> is to read the PHC along with the latency to perform PHC-read as
> offered by PTP_SYS_OFFSET_EXTENDED which provides pre and post
> timestamps. However, these timestamps are currently limited
> to the CLOCK_REALTIME timebase. Since CLOCK_REALTIME is affected
> by NTP (or similar time synchronization services), it can
> experience significant jumps forward or backward. This hinders
> the precise latency measurements that PTP_SYS_OFFSET_EXTENDED
> is designed to provide.
>
> This problem could be addressed by supporting MONOTONIC_RAW
> timestamps within PTP_SYS_OFFSET_EXTENDED. Unlike CLOCK_REALTIME
> or CLOCK_MONOTONIC, the MONOTONIC_RAW timebase is unaffected
> by NTP adjustments.
>
> This enhancement can be implemented by utilizing one of the three
> reserved words within the PTP_SYS_OFFSET_EXTENDED struct to pass
> the clock-id for timestamps. The current behavior aligns with
> clock-id for CLOCK_REALTIME timebase (value of 0), ensuring
> backward compatibility of the UAPI.
>
> Signed-off-by: Mahesh Bandewar <maheshb@...gle.com>
LGTM, but let's wait a bit for Richard ack.
@Richard, could you please have look?
Paolo
Powered by blists - more mailing lists