netdev - Re: [PATCH net] Revert "net/mlx5: Update cyclecounter shift value to improve ptp free running mode precision"

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: <87zg2qhcqh.fsf@nvidia.com>
Date: Wed, 16 Aug 2023 14:57:26 -0700
From: Rahul Rameshbabu <rrameshbabu@...dia.com>
To: Vadim Fedorenko <vadfed@...a.com>
Cc: Gal Pressman <gal@...dia.com>,  Bar Shapira <bshapira@...dia.com>,
  Vadim Fedorenko <vadim.fedorenko@...ux.dev>,  Saeed Mahameed
 <saeedm@...dia.com>,  Jakub Kicinski <kuba@...nel.org>,  Richard Cochran
 <richardcochran@...il.com>,  <netdev@...r.kernel.org>
Subject: Re: [PATCH net] Revert "net/mlx5: Update cyclecounter shift value
 to improve ptp free running mode precision"

On Tue, 15 Aug, 2023 09:53:27 -0700 Rahul Rameshbabu <rrameshbabu@...dia.com> wrote:
> On Tue, 15 Aug, 2023 08:15:07 -0700 Vadim Fedorenko <vadfed@...a.com> wrote:
>> From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
>>
>> This reverts commit 6a40109275626267ebf413ceda81c64719b5c431.
>>
>> There was an assumption in the original commit that all the devices
>> supported by mlx5 advertise 1GHz as an internal timer frequency.
>> Apparently at least ConnectX-4 Lx (MCX4431N-GCAN) provides 156.250Mhz
>> as an internal frequency and the original commit breaks PTP
>> synchronization on these cards.
>>
>> Signed-off-by: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
>> ---
>
> I agree with this revert. This change was made with the assumption that
> all mlx5 compatible devices were running a 1Ghz internal timer. Will
> sync with folks internally about how we can support higher precision
> free running mode while accounting for the different device timer clock
> speeds.

I have prepared a patch that resolves the issue of selecting a valid
shift constant based on the device frequency. The patch includes logic
for picking the optimal shift constant for PTP frequency adjustment
based on the device frequency. I have tested this against a variety of
mlx5 devices and believe this solution would be ideal. I expect this
patch to make its way to the mailing list by the end of the week.

--
Thanks,

Rahul Rameshbabu