Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
MIME-Version: 1.0
References: <20231003041701.1745953-1-maheshb@google.com>
In-Reply-To: <20231003041701.1745953-1-maheshb@google.com>
From:   John Stultz <jstultz@google.com>
Date:   Fri, 6 Oct 2023 15:24:44 -0700
Message-ID: <CANDhNCrG7kY=zZxP=079iGHxsapmHj0Lo1-gCEmcLg3=qJomug@mail.gmail.com>
Subject: Re: [PATCHv2 next 1/3] ptp: add ptp_gettimex64any() support
To:     Mahesh Bandewar <maheshb@google.com>
Cc:     Netdev <netdev@vger.kernel.org>,
        Linux <linux-kernel@vger.kernel.org>,
        David Miller <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Don Hatchett <hatch@google.com>,
        Yuliang Li <yuliangli@google.com>,
        Mahesh Bandewar <mahesh@bandewar.net>,
        Richard Cochran <richardcochran@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Oct 2, 2023 at 9:17=E2=80=AFPM Mahesh Bandewar <maheshb@google.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@google.com>
> CC: Richard Cochran <richardcochran@gmail.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: netdev@vger.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_k=
ernel.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 se=
cond
>   *               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 timestam=
ps from
> + *               the clock of choice. The first reading is made right be=
fore
> + *               reading the lowest bits of the PHC timestamp and the se=
cond
> + *               reading immediately follows that.
> + *               parameter type: any one of the TS opt from ptp_timestam=
p_types.
> + *
>   * @getcrosststamp:  Reads the current time from the hardware clock and
>   *                   system clock simultaneously.
>   *                   parameter cts: Contains timestamp (device,system) p=
air,
> @@ -180,6 +189,9 @@ struct ptp_clock_info {
>         int (*gettime64)(struct ptp_clock_info *ptp, struct timespec64 *t=
s);
>         int (*gettimex64)(struct ptp_clock_info *ptp, struct timespec64 *=
ts,
>                           struct ptp_system_timestamp *sts);
> +       int (*gettimex64any)(struct ptp_clock_info *ptp, struct timespec6=
4 *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 timespec6=
4 *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