netdev - Re: [net-next 03/15] net/mlx5: Add adjphase function to support hardware-only offset control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87r0vpcch0.fsf@nvidia.com>
Date:   Fri, 20 Jan 2023 10:00:59 -0800
From:   Rahul Rameshbabu <rrameshbabu@...dia.com>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Saeed Mahameed <saeed@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Saeed Mahameed <saeedm@...dia.com>, <netdev@...r.kernel.org>,
        Tariq Toukan <tariqt@...dia.com>,
        Gal Pressman <gal@...dia.com>,
        Richard Cochran <richardcochran@...il.com>,
        Vincent Cheng <vincent.cheng.xh@...esas.com>
Subject: Re: [net-next 03/15] net/mlx5: Add adjphase function to support
 hardware-only offset control

On Fri, 20 Jan, 2023 09:21:09 -0800 Jacob Keller <jacob.e.keller@...el.com> wrote:
> On 1/19/2023 8:26 PM, Rahul Rameshbabu wrote:
>> On Thu, 19 Jan, 2023 20:03:43 -0800 Jakub Kicinski <kuba@...nel.org> wrote:
>>> The other question is about the exact semantics of ->adjphase
>>> - do all timecounter based clock implementations support it
>>> by definition?
>> 
>> My understanding is no (though anyone is free to jump in to correct me
>> on this). Only implementations with support for precisely handling small
>> PPS corrections can support adjphase (being able to adjust small offsets
>> without causing same or worse drift).
>
> I guess I'm missing something here? timecounters allow adjusting time in
> an atomic way. They don't lose any time when making an adjustment
> because its a change to the wrapping around a fixed cycle counter.

If that's the case, wouldn't adjphase be implementable by every PTP
hardware clock device. I agree with the description here but not all
devices provide this atomic (phase offset control) functionality from my
understanding. More details in next section.

>
> How does that not comply with adjphase? and if it doesn't, then whats
> the difference between adjphase and just correcting offset using adjfine
> for frequency adjustment?

  Some PTP hardware clocks have a write phase mode that has a built-in
  hardware filtering capability. The write phase mode utilizes a phase
  offset control word instead of a frequency offset control word.

The above is from the original patch description for adjphase. My
understanding is that some PTP hardware clocks do not implement the
phase control word. Hence why I responded with no in my original post as
in no, not all PTP hardware devices are expected to support this
capability.

>
> I guess adjusting phase will do the small corrections in hardware
> (perhaps by temporarily adjusting the nominal frequency of the clock)
> but will then return to the normal frequency once complete?
>
> So adjphase is more than just being atomic...?

I assumed the phase control word is more than just a simple one-shot
(atomic) time offset done in the hardware (at least internally what the
hardware does when implementing this control word).

  adjtime modifies HW counter with a value to move the 1 PPS abruptly to new location.
  adjphase modifies the frequency to quickly nudge the 1 PPS to new location and also includes a HW filter to smooth out the adjustments and fine tune frequency.

  Continuous small offset adjustments using adjtime, likley see sudden shifts of the 1 PPS.  The 1 PPS probably disappears and re-appears.
  Continuous small offset adjustments using adjphase, should see continuous 1 PPS.

https://lore.kernel.org/lkml/20220804132902.GA25315@renesas.com/

Looking at the mlx5 driver implementation, it does look like a simple
atomic operation. That said, I wouldn't consider myself a ptp architect
and am mostly going off based on what I read from the patch series that
introduced the capability in the ptp core stack in the kernel. I do
think this needs to get updated in ptp_clock_kernel.h.