On Tue, 2019-06-04 at 02:15 +0000, Bshara, Nafea wrote: > Andrew, > > Sent from my iPhone > > On Jun 3, 2019, at 6:52 PM, Andrew Lunn <and...@lunn.ch> wrote: > > > > 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 > > > > It may be true for old GbE PHYs where it’s a discrete chip from the > likes of Marvell or broadcom > > But at 25/50/100G, the PHy is actually part of the nic. It’s a very > complex SERDES. Cloud providers like us spend enormous amount of > time testing the PHY across process and voltage variations, all cable > types, length and manufacturing variations, and against all switches > we use. Community drivers won’t be able to validate and tune all > this. > > Plus we would need exact same setting for Linux, including all > distributions even 10year old like RHEL6, for all Windows, ESX, DPDK, > FreeBSD, and support millions of different customers with different > sets of Machine images. > > In this case, there is no practical choice by have the firmware to > manage the PHY
I don't quite know why we're talking about PHYs in this context. ENA is basically a virtio NIC. It has no PHY.
smime.p7s
Description: S/MIME cryptographic signature
