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: <14e5bddf-9071-55b9-a655-7ea9717d33b4@intel.com>
Date:   Mon, 23 Jan 2023 11:13:35 -0800
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Rahul Rameshbabu <rrameshbabu@...dia.com>,
        Richard Cochran <richardcochran@...il.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>,
        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 1/23/2023 10:44 AM, Rahul Rameshbabu wrote:
> Thanks for the followup. Have a couple more questions.
> 
> On Sun, 22 Jan, 2023 18:58:48 -0800 Richard Cochran <richardcochran@...il.com> wrote:
>> On Sun, Jan 22, 2023 at 06:48:49PM -0800, Rahul Rameshbabu wrote:
>>
>>> Another question then is can adjtime/ADJ_SETOFFSET make use of this
>>> servo implementation on the device or is there a strict expectation that
>>> adjtime/ADJ_SETOFFSET is purely a function that adds the offset to the
>>> current current time?
>>
>> ADJ_SETOFFSET == clock_settime.  Drivers should set the time
>> immediately.
>>
>>> If adjphase is implemented by a driver, should
>>> ADJ_SETOFFSET try to make use of it in the ptp stack if the offset
>>> provided is supported by the adjphase implementation?
>>
>> No.
>>
>>
>> BTW, as mentioned in the thread, the KernelDoc is really, really bad:
>>
>>  * @adjphase:  Adjusts the phase offset of the hardware clock.
>>  *             parameter delta: Desired change in nanoseconds.
>>
>> The change log is much better:
>>
>>     ptp: Add adjphase function to support phase offset control.
>>
>>     Adds adjust phase function to take advantage of a PHC
>>     clock's hardware filtering capability that uses phase offset
>>     control word instead of frequency offset control word.
>>
>> So the Kernel Doc should say something like:
>>
>>  * @adjphase:  Feeds the given phase offset into the hardware clock's servo.
>>  *             parameter delta: Measured phase offset in nanoseconds.
> 
> Questions based on the proposed doc change.
> 
> 1. Can the PHC servo change the frequency and not be expected to reset
>    it back to the frequency before the phase control word is issued? If
>    it's an expectation for the phase control word to reset the frequency
>    back, I think that needs to be updated in the comments as a
>    requirement.


My understanding from what Richard said is that .adjphase basically
offloads the entire servo and corrections to the hardware, and thus
would become responsible for maintaining the phase correction long term,
and callers would not use both .adjphase at the same time as .adjtime or
.adjfine

> 2. Is it expected that a PHC servo implementation has a fixed
>    configuration? In userspace servo implementations, configuration
>    parameters are supported. Would we need devlink parameters to support
>    configuring a PHC servo?
> 

I would assume some sort of parameter configuration, either via devlink
or something in the ptp_clock ecosystem if we get a device that has such
configuration?

>>
>> Thanks,
>> Richard