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:   Tue, 4 Jun 2019 03:50:43 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     "Woodhouse, David" <dwmw@...zon.co.uk>,
        "Jubran, Samih" <sameehj@...zon.com>,
        "Kiyanovski, Arthur" <akiyano@...zon.com>,
        "Bshara, Saeed" <saeedb@...zon.com>,
        "Tzalik, Guy" <gtzalik@...zon.com>,
        "Matushevsky, Alexander" <matua@...zon.com>,
        "Liguori, Anthony" <aliguori@...zon.com>,
        "Saidi, Ali" <alisaidi@...zon.com>,
        "Machulsky, Zorik" <zorik@...zon.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Wilson, Matt" <msw@...zon.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "Belgazal, Netanel" <netanel@...zon.com>,
        "Bshara, Nafea" <nafea@...zon.com>,
        "Herrenschmidt, Benjamin" <benh@...zon.com>
Subject: Re: [PATCH V2 net 00/11] Extending the ena driver to support new
 features and enhance performance

> Any "SmartNIC" vendor has temptation of uAPI-level hand off to the
> firmware (including my employer), we all run pretty beefy processors
> inside "the NIC" after all.  The device centric ethtool configuration
> can be implemented by just forwarding the uAPI structures as they are
> to the FW.  I'm sure Andrew and others who would like to see Linux
> takes more control over PHYs etc. would not like this scenario, either.

No, i would not. There are a few good examples of both firmware and
open drivers being used to control the same PHY, on different
boards. The PHY driver was developed by the community, and has more
features than the firmware driver. And it keeps gaining features. The
firmware i stuck, no updates. The community driver can be debugged,
the firmware is a black box, no chance of the community fixing any
bugs in it.

And PHYs are commodity devices. I doubt there is any value add in the
firmware for a PHY, any real IPR which makes the product better, magic
sauce related to the PHY. So just save the cost of writing and
maintaining firmware, export the MDIO bus, and let Linux control it.
Concentrate the engineers on the interesting parts of the NIC, the
Smart parts, where there can be real IPR.

And i would say this is true for any NIC. Let Linux control the PHY.

      Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ