From: Andrew Lunn <andrew@lunn.ch>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: "Woodhouse, David" <dwmw@amazon.co.uk>,
"Jubran, Samih" <sameehj@amazon.com>,
"Kiyanovski, Arthur" <akiyano@amazon.com>,
"Bshara, Saeed" <saeedb@amazon.com>,
"Tzalik, Guy" <gtzalik@amazon.com>,
"Matushevsky, Alexander" <matua@amazon.com>,
"Liguori, Anthony" <aliguori@amazon.com>,
"Saidi, Ali" <alisaidi@amazon.com>,
"Machulsky, Zorik" <zorik@amazon.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Wilson, Matt" <msw@amazon.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"Belgazal, Netanel" <netanel@amazon.com>,
"Bshara, Nafea" <nafea@amazon.com>,
"Herrenschmidt, Benjamin" <benh@amazon.com>
Subject: Re: [PATCH V2 net 00/11] Extending the ena driver to support new features and enhance performance
Date: Tue, 4 Jun 2019 03:50:43 +0200 [thread overview]
Message-ID: <20190604015043.GG17267@lunn.ch> (raw)
In-Reply-To: <20190603160351.085daa91@cakuba.netronome.com>
> 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
next prev parent reply other threads:[~2019-06-04 1:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 14:43 [PATCH V2 net 00/11] Extending the ena driver to support new features and enhance performance sameehj
2019-06-03 14:43 ` [PATCH V2 net 01/11] net: ena: add handling of llq max tx burst size sameehj
2019-06-03 14:43 ` [PATCH V2 net 02/11] net: ena: ethtool: add extra properties retrieval via get_priv_flags sameehj
2019-06-03 14:43 ` [PATCH V2 net 03/11] net: ena: replace free_tx/rx_ids union with single free_ids field in ena_ring sameehj
2019-06-03 14:43 ` [PATCH V2 net 04/11] net: ena: arrange ena_probe() function variables in reverse christmas tree sameehj
2019-06-03 14:43 ` [PATCH V2 net 05/11] net: ena: add newline at the end of pr_err prints sameehj
2019-06-03 14:43 ` [PATCH V2 net 06/11] net: ena: documentation: update ena.txt sameehj
2019-06-03 14:43 ` [PATCH V2 net 07/11] net: ena: allow automatic fallback to polling mode sameehj
2019-06-03 14:43 ` [PATCH V2 net 08/11] net: ena: add support for changing max_header_size in LLQ mode sameehj
2019-06-03 14:43 ` [PATCH V2 net 09/11] net: ena: optimise calculations for CQ doorbell sameehj
2019-06-03 14:43 ` [PATCH V2 net 10/11] net: ena: add good checksum counter sameehj
2019-06-03 14:43 ` [PATCH V2 net 11/11] net: ena: use dev_info_once instead of static variable sameehj
2019-06-03 20:30 ` [PATCH V2 net 00/11] Extending the ena driver to support new features and enhance performance David Miller
2019-06-03 21:32 ` Jakub Kicinski
[not found] ` <9da931e72debc868efaac144082f40d379c50f3c.camel@amazon.co.uk>
2019-06-03 23:03 ` Jakub Kicinski
2019-06-04 1:50 ` Andrew Lunn [this message]
2019-06-04 2:15 ` Bshara, Nafea
2019-06-04 6:57 ` David Woodhouse
2019-06-04 17:24 ` Jakub Kicinski
2019-06-06 10:23 ` Jubran, Samih
2019-06-06 17:16 ` Jakub Kicinski
2019-06-06 21:40 ` Bshara, Nafea
2019-06-06 22:04 ` Jakub Kicinski
2019-06-06 22:57 ` Bshara, Nafea
2019-06-06 23:07 ` Jakub Kicinski
2019-06-06 23:21 ` Bshara, Nafea
2019-06-06 23:42 ` Jakub Kicinski
2019-06-07 1:04 ` Bshara, Nafea
2019-06-07 1:14 ` Jakub Kicinski
2019-06-07 21:27 ` Jakub Kicinski
2019-06-07 21:34 ` Bshara, Nafea
2019-06-07 21:54 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190604015043.GG17267@lunn.ch \
--to=andrew@lunn.ch \
--cc=akiyano@amazon.com \
--cc=aliguori@amazon.com \
--cc=alisaidi@amazon.com \
--cc=benh@amazon.com \
--cc=davem@davemloft.net \
--cc=dwmw@amazon.co.uk \
--cc=gtzalik@amazon.com \
--cc=jakub.kicinski@netronome.com \
--cc=matua@amazon.com \
--cc=msw@amazon.com \
--cc=nafea@amazon.com \
--cc=netanel@amazon.com \
--cc=netdev@vger.kernel.org \
--cc=saeedb@amazon.com \
--cc=sameehj@amazon.com \
--cc=zorik@amazon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).