Message-ID: <CANDhNCrG7kY=zZxP=079iGHxsapmHj0Lo1-gCEmcLg3=qJomug@mail.gmail.com>
Date: Fri, 6 Oct 2023 15:24:44 -0700
From: John Stultz <jstultz@...gle.com>
To: Mahesh Bandewar <maheshb@...gle.com>
Cc: 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>, Paolo Abeni <pabeni@...hat.com>, 
	Jonathan Corbet <corbet@....net>, Don Hatchett <hatch@...gle.com>, Yuliang Li <yuliangli@...gle.com>, 
	Mahesh Bandewar <mahesh@...dewar.net>, Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCHv2 next 1/3] ptp: add ptp_gettimex64any() support

On Mon, Oct 2, 2023 at 9:17 PM Mahesh Bandewar <maheshb@...gle.com> wrote:
>
> add support for TS sandwich of the user preferred timebase. The options
> supported are PTP_TS_REAL (CLOCK_REALTIME), PTP_TS_MONO (CLOCK_MONOTONIC),
> and PTP_TS_RAW (CLOCK_MONOTONIC_RAW)
>
> Option of PTP_TS_REAL is equivalent of using ptp_gettimex64().
>
> Signed-off-by: Mahesh Bandewar <maheshb@...gle.com>
> CC: Richard Cochran <richardcochran@...il.com>
> CC: "David S. Miller" <davem@...emloft.net>
> CC: netdev@...r.kernel.org
> ---
>  include/linux/ptp_clock_kernel.h | 51 ++++++++++++++++++++++++++++++++
>  include/uapi/linux/ptp_clock.h   |  7 +++++
>  2 files changed, 58 insertions(+)

Hey Mahesh,
  Thanks for sending this out!  I've got a few thoughts below.


> diff --git a/include/linux/ptp_clock_kernel.h b/include/linux/ptp_clock_kernel.h
> index 1ef4e0f9bd2a..fd7be98e7bba 100644
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @@ -102,6 +102,15 @@ struct ptp_system_timestamp {
>   *               reading the lowest bits of the PHC timestamp and the second
>   *               reading immediately follows that.
>   *
> + * @gettimex64any:  Reads the current time from the hardware clock and
> +                 optionally also any of the MONO, MONO_RAW, or SYS clock.
> + *               parameter ts: Holds the PHC timestamp.
> + *               parameter sts: If not NULL, it holds a pair of timestamps from
> + *               the clock of choice. The first reading is made right before
> + *               reading the lowest bits of the PHC timestamp and the second
> + *               reading immediately follows that.
> + *               parameter type: any one of the TS opt from ptp_timestamp_types.
> + *
>   * @getcrosststamp:  Reads the current time from the hardware clock and
>   *                   system clock simultaneously.
>   *                   parameter cts: Contains timestamp (device,system) pair,
> @@ -180,6 +189,9 @@ struct ptp_clock_info {
>         int (*gettime64)(struct ptp_clock_info *ptp, struct timespec64 *ts);
>         int (*gettimex64)(struct ptp_clock_info *ptp, struct timespec64 *ts,
>                           struct ptp_system_timestamp *sts);
> +       int (*gettimex64any)(struct ptp_clock_info *ptp, struct timespec64 *ts,
> +                            struct ptp_system_timestamp *sts,
> +                            enum ptp_ts_types type);
>         int (*getcrosststamp)(struct ptp_clock_info *ptp,
>                               struct system_device_crosststamp *cts);
>         int (*settime64)(struct ptp_clock_info *p, const struct timespec64 *ts);

So I don't see anything in this series that wires into this hook. Did
a patch go missing? Or am I maybe looking in the wrong place?


> @@ -464,4 +476,43 @@ static inline void ptp_read_system_postts(struct ptp_system_timestamp *sts)
>                 ktime_get_real_ts64(&sts->post_ts);
>  }
>
> +static inline void ptp_read_any_prets(struct ptp_system_timestamp *sts,
> +                                     enum ptp_ts_types type)
> +{
> +       if (sts) {
> +               switch (type) {
> +               case PTP_TS_REAL:
> +                       ktime_get_real_ts64(&sts->pre_ts);
> +                       break;
> +               case PTP_TS_MONO:
> +                       ktime_get_ts64(&sts->pre_ts);
> +                       break;
> +               case PTP_TS_RAW:
> +                       ktime_get_raw_ts64(&sts->pre_ts);
> +                       break;
> +               default:
> +                       break;
> +               }
> +       }
> +}
> +
> +static inline void ptp_read_any_postts(struct ptp_system_timestamp *sts,
> +                                      enum ptp_ts_types type)
> +{
> +       if (sts) {
> +               switch (type) {
> +               case PTP_TS_REAL:
> +                       ktime_get_real_ts64(&sts->post_ts);
> +                       break;
> +               case PTP_TS_MONO:
> +                       ktime_get_ts64(&sts->post_ts);
> +                       break;
> +               case PTP_TS_RAW:
> +                       ktime_get_raw_ts64(&sts->post_ts);
> +                       break;
> +               default:
> +                       break;
> +               }
> +       }
> +}

Similarly, I'm a little confused as to who the users of these two
functions are? I don't see them in this patch series.

Additionally it seems like instead of two functions, you could maybe
have one ptp_read_any_ts(enum ptp_ts_types type, struct timespec64
*ts) function that the caller passes the sts->pre_ts or sts->post_ts
to?

And finally, I'm not sure if it makes sense, but other logic in the
kernel that does similar clockid multiplexing includes
timens_add_monotonic() or timens_add_boottime() (though the latter
doesn't apply here) for namespace offsets.
I was never excited about time namespaces (hard enough to keep one
sense of time :), but there are some good reasons, and I suspect we
might want to avoid cases where clock_gettime() returns potentially
different values compared to this interface.

thanks again!
-john

Powered by blists - more mailing lists