netdev - Re: [PATCH iwl-net] ice: fix incorrect PHY settings for 100 GB/s

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: <6cca6089-ed72-407a-8f23-70bb67b42e63@intel.com>
Date: Thu, 28 Nov 2024 16:58:37 +0100
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: "Korba, Przemyslaw" <przemyslaw.korba@...el.com>, Richard Cochran
	<richardcochran@...il.com>
CC: "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	Andrew Lunn <andrew@...n.ch>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
	"Olech, Milena" <milena.olech@...el.com>, Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH iwl-net] ice: fix incorrect PHY settings for 100 GB/s

On 11/27/24 14:19, Korba, Przemyslaw wrote:
>> On Tue, Nov 26, 2024 at 11:23:11AM +0100, Przemyslaw Korba wrote:
>>> ptp4l application reports too high offset when ran on E823 device with
>>> a 100GB/s link. Those values cannot go under 100ns, like in a PTP
>>> working case when using 100 GB/s cable.
>>> This is due to incorrect frequency settings on the PHY clocks for
>>> 100 GB/s speed. Changes are introduced to align with the internal
>>> hardware documentation, and correctly initialize frequency in PHY
>>> clocks with the frequency values that are in our HW spec.
>>> To reproduce the issue run ptp4l as a Time Receiver on E823 device,
>>> and observe the offset, which will never approach values seen in the
>>> PTP working case.
>>
>> You forgot to Cc: the PTP maintainer.
> 
> Who is the PTP maintainer? Is it necessary? This is only Intel's driver,
> I am not sure if PTP maintainer is necessary.

I was curious for a moment too, but just for a moment :)

We develop network drivers in the public, so we CC people which could
have a valuable feedback. For PTP code it's PTP Maintainer, and other
PTP folks. I'm not sure how interested they are though, @Richard?
@Vladimir?


In general it is similar to why we CC netdev. The difference is that
this code will not go via PTP Maintainer, but it does not matter that
much for the review/design purposes.

> 
>>
>> If i spent the time to measure the latency and configured ptp4l correctly to take
>> into account the latency, would i not see this issue? And will this change then
>> cause a regression because it changes the latency invalidating my measurements?
>>
> 
> I don't think ptp4l config, or configured latency has anything to do with that, you should
> still see issue with any configured latency. due to incorrect PHY settings there was incorrect
> calculation in Vernier algorithm. Not much to do with latency. The Problem was that the offset
> was quite far off,  I will attach logs in commit message once the window is opened. I did not test
> with other ptp4l configs other than the standard one. Thanks for reviewing by the way! : )
> 
>>      Andrew