On 4/8/24 09:51, Jiri Pirko wrote:
Mon, Apr 08, 2024 at 05:46:35PM CEST, alexander.duyck@xxxxxxxxx wrote:
On Mon, Apr 8, 2024 at 4:51 AM Jiri Pirko <jiri@xxxxxxxxxxx> wrote:
Fri, Apr 05, 2024 at 08:38:25PM CEST, alexander.duyck@xxxxxxxxx wrote:
On Fri, Apr 5, 2024 at 8:17 AM Jason Gunthorpe <jgg@xxxxxxxxxx> wrote:
On Fri, Apr 05, 2024 at 07:24:32AM -0700, Alexander Duyck wrote:
Alex already indicated new features are coming, changes to the core
code will be proposed. How should those be evaluated? Hypothetically
should fbnic be allowed to be the first implementation of something
invasive like Mina's DMABUF work? Google published an open userspace
for NCCL that people can (in theory at least) actually run. Meta would
not be able to do that. I would say that clearly crosses the line and
should not be accepted.
Why not? Just because we are not commercially selling it doesn't mean
we couldn't look at other solutions such as QEMU. If we were to
provide a github repo with an emulation of the NIC would that be
enough to satisfy the "commercial" requirement?
My test is not "commercial", it is enabling open source ecosystem vs
benefiting only proprietary software.
Sorry, that was where this started where Jiri was stating that we had
to be selling this.
For the record, I never wrote that. Not sure why you repeat this over
this thread.
Because you seem to be implying that the Meta NIC driver shouldn't be
included simply since it isn't going to be available outside of Meta.
The fact is Meta employs a number of kernel developers and as a result
of that there will be a number of kernel developers that will have
access to this NIC and likely do development on systems containing it.
In addition simply due to the size of the datacenters that we will be
populating there is actually a strong likelihood that there will be
more instances of this NIC running on Linux than there are of some
other vendor devices that have been allowed to have drivers in the
kernel.
So? The gain for community is still 0. No matter how many instances is
private hw you privately have. Just have a private driver.
I am amazed and not in a good way at how far this has gone, truly.
This really is akin to saying that any non-zero driver count to maintain
is a burden on the community. Which is true, by definition, but if the
goal was to build something for no users, then clearly this is the wrong
place to be in, or too late. The systems with no users are the best to
maintain, that is for sure.
If the practical concern is wen you make tree wide API change that fbnic
happens to use, and you have yet another driver (fbnic) to convert, so
what? Work with Alex ahead of time, get his driver to be modified, post
the patch series. Even if Alex happens to move on and stop being
responsible and there is no maintainer, so what? Give the driver a
depreciation window for someone to step in, rip it, end of story.
Nothing new, so what has specifically changed as of April 4th 2024 to
oppose such strong rejection?
Like it was said, there are tons of drivers in the Linux kernel that
have a single user, this one might have a few more than a single one,
that should be good enough.
What the heck is going on?
--
Florian
