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: <ZME/GjBWdodiUO+8@hoboy.vegasvil.org>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ