On 4/10/24 09:42, Jiri Pirko wrote:
Tue, Apr 09, 2024 at 10:51:42PM CEST, kuba@xxxxxxxxxx wrote:
On Wed, 03 Apr 2024 13:08:24 -0700 Alexander Duyck wrote:
This patch set includes the necessary patches to enable basic Tx and Rx
over the Meta Platforms Host Network Interface. To do this we introduce a
new driver and driver and directories in the form of
"drivers/net/ethernet/meta/fbnic".
Let me try to restate some takeaways and ask for further clarification
on the main question...
First, I think there's broad support for merging the driver itself.
IIUC there is also broad support to raise the expectations from
maintainers of drivers for private devices, specifically that they will:
- receive weaker "no regression" guarantees
- help with refactoring / adapting their drivers more actively
:)
- not get upset when we delete those drivers if they stop participating
Sorry for being pain, but I would still like to see some sumarization of
what is actually the gain for the community to merge this unused driver.
So far, I don't recall to read anything solid.
For me personally, both as a developer and as an user, any movement into
lean-FW direction is a breeze of fresh air.
And nobody is stopping Nvidia or other vendor from manufacturing
Advanced FBNIC Accelerator TM, that uses the driver as-is, but makes it
faster, better and cheaper that anything you could buy right now.
btw:
Kconfig description should contain:
Say N here, you can't ever see this device in real world.
Thank you for keeping this entertaining :)
If you think that the drivers should be merged *without* setting these
expectations, please speak up.
Nobody picked me up on the suggestion to use the CI as a proactive
check whether the maintainer / owner is still paying attention,
but okay :(
What is less clear to me is what do we do about uAPI / core changes.
Of those who touched on the subject - few people seem to be curious /
welcoming to any reasonable features coming out for private devices
(John, Olek, Florian)? Others are more cautious focusing on blast
radius and referring to the "two driver rule" (Daniel, Paolo)?
Whether that means outright ban on touching common code or uAPI
in ways which aren't exercised by commercial NICs, is unclear.
For these kind of unused drivers, I think it would be legit to
disallow any internal/external api changes. Just do that for some
normal driver, then benefit from the changes in the unused driver.
Now the question is, how to distinguish these 2 driver kinds? Maybe to
put them under some directory so it is clear?
drivers/net/unused/ethernet/meta/fbnic/
Andrew and Ed did not address the question directly AFAICT.
Is my reading correct? Does anyone have an opinion on whether we should
try to dig more into this question prior to merging the driver, and
set some ground rules? Or proceed and learn by doing?
