netdev - RE: [Intel-wired-lan] [PATCH iwl-next v2 5/5] ice: implement low latency PHY timer updates

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: <IA1PR11MB62419E7526353478FD9593778B022@IA1PR11MB6241.namprd11.prod.outlook.com>
Date: Mon, 23 Dec 2024 16:28:14 +0000
From: "Rinitha, SX" <sx.rinitha@...el.com>
To: "Nadezhdin, Anton" <anton.nadezhdin@...el.com>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Nguyen, Anthony L"
	<anthony.l.nguyen@...el.com>, "Kitszel, Przemyslaw"
	<przemyslaw.kitszel@...el.com>, "richardcochran@...il.com"
	<richardcochran@...il.com>, "Keller, Jacob E" <jacob.e.keller@...el.com>,
	"Kolacinski, Karol" <karol.kolacinski@...el.com>, "Olech, Milena"
	<milena.olech@...el.com>, "Nadezhdin, Anton" <anton.nadezhdin@...el.com>
Subject: RE: [Intel-wired-lan] [PATCH iwl-next v2 5/5] ice: implement low
 latency PHY timer updates

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of Anton Nadezhdin
> Sent: 16 December 2024 20:24
> To: intel-wired-lan@...ts.osuosl.org
> Cc: netdev@...r.kernel.org; Nguyen, Anthony L <anthony.l.nguyen@...el.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@...el.com>; richardcochran@...il.com; Keller, Jacob E <jacob.e.keller@...el.com>; Kolacinski, Karol <karol.kolacinski@...el.com>; Olech, Milena <milena.olech@...el.com>; Nadezhdin, Anton <anton.nadezhdin@...el.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v2 5/5] ice: implement low latency PHY timer updates
>
> From: Jacob Keller <jacob.e.keller@...el.com>
>
> Programming the PHY registers in preparation for an increment value change or a timer adjustment on E810 requires issuing Admin Queue commands for each PHY register. It has been found that the firmware Admin Queue processing occasionally has delays of tens or rarely up to hundreds of milliseconds. This delay cascades to failures in the PTP applications which depend on these updates being low latency.
>
> Consider a standard PTP profile with a sync rate of 16 times per second.
> This means there is ~62 milliseconds between sync messages. A complete cycle of the PTP algorithm
>
> 1) Sync message (with Tx timestamp) from source
> 2) Follow-up message from source
> 3) Delay request (with Tx timestamp) from sink
> 4) Delay response (with Rx timestamp of request) from source
> 5) measure instantaneous clock offset
> 6) request time adjustment via CLOCK_ADJTIME systemcall
>
> The Tx timestamps have a default maximum timeout of 10 milliseconds. If we assume that the maximum possible time is used, this leaves us with ~42 milliseconds of processing time for a complete cycle.
>
> The CLOCK_ADJTIME system call is synchronous and will block until the driver completes its timer adjustment or frequency change.
>
> If the writes to prepare the PHY timers get hit by a latency spike of 50 milliseconds, then the PTP application will be delayed past the point where the next cycle should start. Packets from the next cycle may have already arrived and are waiting on the socket.
>
> In particular, LinuxPTP ptp4l may start complaining about missing an announce message from the source, triggering a fault. In addition, the clockcheck logic it uses may trigger. This clockcheck failure occurs because the timestamp captured by hardware is compared against a reading of CLOCK_MONOTONIC. It is assumed that the time when the Rx timestamp is captured and the read from CLOCK_MONOTONIC are relatively close together.
> This is not the case if there is a significant delay to processing the Rx packet.
>
> Newer firmware supports programming the PHY registers over a low latency interface which bypasses the Admin Queue. Instead, software writes to the REG_LL_PROXY_L and REG_LL_PROXY_H registers. Firmware reads these registers and then programs the PHY timers.
>
> Implement functions to use this interface when available to program the PHY timers instead of using the Admin Queue. This avoids the Admin Queue latency and ensures that adjustments happen within acceptable latency bounds.
>
> Co-developed-by: Karol Kolacinski <karol.kolacinski@...el.com>
> Signed-off-by: Karol Kolacinski <karol.kolacinski@...el.com>
> Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>
> Reviewed-by: Milena Olech <milena.olech@...el.com>
> Signed-off-by: Anton Nadezhdin <anton.nadezhdin@...el.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 105 ++++++++++++++++++++
> drivers/net/ethernet/intel/ice/ice_ptp_hw.h |   4 +
> 2 files changed, 109 insertions(+)
>
Tested-by: Rinitha S <sx.rinitha@...el.com> (A Contingent worker at Intel)