Message-ID: <87fs70wh7n.fsf@nvidia.com>
Date: Fri, 09 Jun 2023 12:47:40 -0700
From: Rahul Rameshbabu <rrameshbabu@...dia.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org,  "David S. Miller" <davem@...emloft.net>,  Jacob
 Keller <jacob.e.keller@...el.com>,  Gal Pressman <gal@...dia.com>,  Tariq
 Toukan <tariqt@...dia.com>,  Saeed Mahameed <saeed@...nel.org>,  Richard
 Cochran <richardcochran@...il.com>,  Vincent Cheng
 <vincent.cheng.xh@...esas.com>
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 <pabeni@...hat.com> wrote:
> 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:
>> On Thu, 25 May, 2023 14:11:51 +0200 Paolo Abeni <pabeni@...hat.com> wrote:
>> > On Thu, 2023-05-25 at 14:08 +0200, Paolo Abeni wrote:
>> > > > 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)
>> > > >  /* 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)
>> > > > +{
>> > > > +	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.
>
>> 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.

>
> 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.

>
> Thanks
>
> Paolo

Thanks,

Rahul Rameshbabu

Powered by blists - more mailing lists