netdev - Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta Platforms Host Network Interface

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: Mon, 8 Apr 2024 08:04:20 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: netdev@...r.kernel.org
Cc: Alexander Duyck <alexander.duyck@...il.com>, Jason Gunthorpe
 <jgg@...dia.com>, Paolo Abeni <pabeni@...hat.com>, John Fastabend
 <john.fastabend@...il.com>, Jiri Pirko <jiri@...nulli.us>,
 bhelgaas@...gle.com, linux-pci@...r.kernel.org, Alexander Duyck
 <alexanderduyck@...com>, davem@...emloft.net, Christoph Hellwig
 <hch@....de>
Subject: Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta
 Platforms Host Network Interface

On Sat, 6 Apr 2024 09:05:01 -0700 Alexander Duyck wrote:
> > I'm being very clear to say that there are some core changes should
> > not be accepted due to the kernel's open source ideology.  
> 
> Okay, on core changes I 100% agree. That is one of the reasons why we
> have the whole thing about any feature really needing to be enabled on
> at least 2 different vendor devices.

The "2 different vendor"/implementation thing came up before so
I wanted to provide more context for the less initiated readers.
We try  to judge features in terms of how reasonable the APIs are,
overall system design and how easy they will be to modify later
(e.g. uAPI, depth of core changes).

Risks are usually more pronounced for stack features like GSO partial,
XDP or AF_XDP. Although my (faulty) memory is that we started with
just mlx4 for XDP and other drivers quickly followed. But we did not
wait for more than an ACK from other vendors.

We almost never have a second implementation for HW-heavy features.
TLS immediately comes to mind, and merging it was probably the right
call given how many implementations were added since. For "full" IPsec
offload we still only have one vendor. Existing TCP ZC Rx (page
flipping) was presented as possible with two NICs but mlx5 was hacked
up and still doesn't support real HDS.

Most (if not all) of recent uAPI we added in netdev netlink were
accepted with a single implementation (be it Intel's work + drivers
or my work, and I often provide just a bnxt implementation).

Summary -> the number of implementations we require is decided on case
by case basis, depending on our level of confidence..

I don't know if this "2 implementations" rule is just a "mental
ellipsis" everyone understands to be a more nuanced rule in practice. 
But to an outsider it would seem very selectively enforced. In worst
case a fake rule to give us an excuse to nack stuff.