netdev - Re: [PATCH v2] net: stmmac: correct MAC propagation delay

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]

Date: Wed, 26 Jul 2023 08:43:22 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Johannes Zink <j.zink@...gutronix.de>
Cc: Jakub Kicinski <kuba@...nel.org>,
	Giuseppe Cavallaro <peppe.cavallaro@...com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Jose Abreu <joabreu@...opsys.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Russell King <linux@...linux.org.uk>, patchwork-jzi@...gutronix.de,
	netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	kernel@...gutronix.de, kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v2] net: stmmac: correct MAC propagation delay

On Wed, Jul 26, 2023 at 08:10:35AM +0200, Johannes Zink wrote:

> Also on a side-note, "driver nonsense" sounds a bit harsh from someone
> always insisting that one should not compensate for bad drivers in the
> userspace stack and instead fixing driver and hardware issues in the kernel,
> don't you think?

Everything has its place.

The proper place to account for delay asymmetries is in the user space
configuration, for example in linuxptp you have

       delayAsymmetry
              The  time  difference in nanoseconds of the transmit and receive
              paths. This value should be positive when  the  server-to-client
              propagation  time  is  longer  and  negative when the client-to-
              server time is longer. The default is 0 nanoseconds.

       egressLatency
              Specifies the  difference  in  nanoseconds  between  the  actual
              transmission time at the reference plane and the reported trans‐
              mit time stamp. This value will be added to egress  time  stamps
              obtained from the hardware.  The default is 0.

       ingressLatency
              Specifies the difference in nanoseconds between the reported re‐
              ceive  time  stamp  and  the  actual reception time at reference
              plane. This value will be subtracted from  ingress  time  stamps
              obtained from the hardware.  The default is 0.

Trying to hard code those into the driver?  Good luck getting that
right for everyone.

BTW this driver is actually for an IP core used in many, many SoCs.

How many _other_ SoCs did you test your patch on?

Thanks,
Richard