-----Original Message-----
From: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Sent: Friday, June 9, 2023 12:48 PM
To: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org; David S. Miller <davem@davemloft.net>; Keller,
Jacob E [off-list ref]; Gal Pressman [off-list ref]; Tariq
Toukan [off-list ref]; Saeed Mahameed [off-list ref]; Richard
Cochran [off-list ref]; Vincent Cheng
[off-list ref]
Subject: Re: [PATCH net-next v2 7/9] ptp: ptp_clockmatrix: Add .getmaxphase
ptp_clock_info callback

On Fri, 09 Jun, 2023 08:38:11 +0200 Paolo Abeni [off-list ref] wrote:

quoted

Hi,

I'm sorry for the late reply. This fell under my radar.

On Thu, 2023-05-25 at 11:09 -0700, Rahul Rameshbabu wrote:

quoted

On Thu, 25 May, 2023 14:11:51 +0200 Paolo Abeni [off-list ref]

wrote:

quoted

quoted

quoted

On Thu, 2023-05-25 at 14:08 +0200, Paolo Abeni wrote:

quoted

quoted

diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
index c9d451bf89e2..f6f9d4adce04 100644
--- a/drivers/ptp/ptp_clockmatrix.c
+++ b/drivers/ptp/ptp_clockmatrix.c

@@ -1692,14 +1692,23 @@ static int

initialize_dco_operating_mode(struct idtcm_channel *channel)

quoted

quoted

quoted

quoted

quoted

 /* PTP Hardware Clock interface */

 /*
- * Maximum absolute value for write phase offset in picoseconds
- *
- * @channel:  channel
- * @delta_ns: delta in nanoseconds
+ * Maximum absolute value for write phase offset in nanoseconds
  *
  * Destination signed register is 32-bit register in resolution of 50ps
  *
- * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350
+ * 0x7fffffff * 50 =  2147483647 * 50 = 107374182350 ps
+ * Represent 107374182350 ps as 107374182 ns
+ */
+static s32 idtcm_getmaxphase(struct ptp_clock_info *ptp

__always_unused)

quoted

quoted

quoted

quoted

quoted

+{
+	return MAX_ABS_WRITE_PHASE_NANOSECONDS;
+}

This introduces a functional change WRT the current code. Prior to this
patch ClockMatrix tries to adjust phase delta even above
MAX_ABS_WRITE_PHASE_NANOSECONDS, limiting the delta to such value.
After this patch it will error out.

My understanding is the syscall for adjphase, clock_adjtime, cannot
represent an offset granularity smaller than nanoseconds using the
struct timex offset member.

Ok.

quoted

To me, it seems that adjusting a delta above
MAX_ABS_WRITE_PHASE_NANOSECONDS (due to support for higher precision
units by the device), while supported by the device driver, would not be
a capability utilized by any interface that would invoke the .adjphase
callback implemented by ClockMatrix.

I see I caused some confusion in terms of what I was focused on with
this response. My main concern here was still about supporting precision
units higher than nanoseconds. For example if a device was capable of
supporting 107374182350 picoseconds for ADJ_OFFSET, it doesn't matter
whether the driver advertises 107374182 nanoseconds as the maximum
adjustment capability versus 107374182350 picoseconds even though
107374182 nanoseconds < 107374182350 picoseconds because the granularity
of the parameter for the adjphase callback is in nanoseconds. I think we
have converged on this topic but not the other point you brought up.

quoted

Here I don't follow. I must admit I know the ptp subsystem very little,
but AFAICS, we could have e.g.

clock_adjtime() // offset > 200 secs (200000000 usec)
 -> do_clock_adjtime
    -> kc->clock_adj
       -> clock_posix_dynamic
          -> pc_clock_adjtime
             -> ptp_clock_adjtime
                -> _idtcm_adjphase // delta land unmodified up here

I guess the user-space could pass such large delta (e.g. at boot
time?!?). If so, with this patch we change an user-space observable
behavior, and I think we should avoid that.

The point that you bring up here is about clamping (which is done by
idtcm_adjphase previously) versus throwing an error when out of range
(what is now done in ptp_clock_adjtime in this patch series). This was
something I was struggling with deciding on a unified behavior across
all drivers. For example, the mlx5_core driver chooses to return -ERANGE
when the delta landed on it is out of the range supported by the PHC of
the device. We chose to return an error because there was no mechanism
previously for the userspace to know what was the supported offset when
using ADJ_OFFSET with different PHC devices. If a user provides an
offset and no error is returned, the user would assume that offset had
been applied (there was no way to know that it was clamped from the
userspace). This patch series now adds the query for maximum supported
offset in the PTP_CLOCK_GETCAPS ioctl. In my opinion, I think we will
see an userspace observable behavior change either way unfortunately due
to the inconsistency among device drivers, which was one of the main
issues this patch submission targets. I am ok with making the common
behavior in ptp_clock_adjtime clamp the provided offset value instead of
throwing an error when out of range. In both cases, userspace programs
can handle the out-of-range case explicitly with a check against the
maximum offset value now advertised in PTP_CLOCK_GETCAPS. My personal
opinion is that since we have this inconsistency among device drivers
for handling out of range offsets that are currently provided as-is to
the driver-specific callback implementations, it makes sense to converge
to a version that returns an error when the userspace provides
out-of-range values rather than silently clamping these values. However,
I am open to either version as long as we have consistency and do not
leave this up to individual device-drivers to dictate since this adds
further complexity in the userspace when working with this syscall.

I'm in favor of throwing an error, since userspace that *doesn't* check for the max value and assumes it will apply without a clamp may be surprised when it starts clamping. Userspace which previously supplied a large value and it clamps now gets an error, which might be concerning, but they got driver defined behavior before, where it might error or it might clamp, so I think we're in a no-win scenario there.

I don't really see the value in clamping because that makes it hard to tell if an update was fully applied or not. Now software has to know to check the range in advance. I wouldn't view a partially applied update as a successful behavior in a timing application. Thus, on the principle of least surprise I would avoid clamping. I'm open to other opinions, and I think standardizing is much better than letting it be driver behavior.

quoted

Thanks

Paolo

Thanks,

Rahul Rameshbabu