Message-ID: <c2f5b7c7-44d0-44d4-b837-0d689b22a1ee@intel.com>
Date: Wed, 10 Apr 2024 14:50:40 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>
CC: <pabeni@...hat.com>, John Fastabend <john.fastabend@...il.com>, "Alexander
 Lobakin" <aleksander.lobakin@...el.com>, Florian Fainelli
	<f.fainelli@...il.com>, Andrew Lunn <andrew@...n.ch>, Daniel Borkmann
	<daniel@...earbox.net>, Edward Cree <ecree.xilinx@...il.com>, Alexander Duyck
	<alexander.duyck@...il.com>, <netdev@...r.kernel.org>, <bhelgaas@...gle.com>,
	<linux-pci@...r.kernel.org>, Alexander Duyck <alexanderduyck@...com>, "Willem
 de Bruijn" <willemdebruijn.kernel@...il.com>
Subject: Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta
 Platforms Host Network Interface

On 4/10/24 09:42, Jiri Pirko wrote:
> Tue, Apr 09, 2024 at 10:51:42PM CEST, kuba@...nel.org 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?
>>
> 

Powered by blists - more mailing lists