On 4/9/2024 3:56 AM, Jiri Pirko wrote:
Mon, Apr 08, 2024 at 11:36:42PM CEST, f.fainelli@xxxxxxxxx wrote:
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?
How you describe the flow of internal API change is totally distant from
reality. Really, like no part is correct:
1) API change is responsibility of the person doing it. Imagine working
with 40 driver maintainers for every API change. I did my share of
API changes in the past, maintainer were only involved to be cced.
As a submitter you propose changes and silence is acknowledgement. If
one of your API changes broke someone's driver and they did not notify
you of the breakage during the review cycle, it falls on their shoulder
to fix it for themselves and they should not be holding back your work,
that would not be fair. If you know about the breakage, and there is
still no fix, that is an indication the driver is not actively used and
maintained.
This also does not mean you have to do the entire API changes to a
driver you do not know about on your own. Nothing ever prevents you from
posting the patches as RFC and say: "here is how I would go about
changing your driver, please review and help me make corrections". If
the driver maintainers do not respond there is no reason their lack of
involvement should refrain your work, and so your proposed changes will
be merged eventually.
Is not this the whole point of being a community and be able to delegate
and mitigate the risk of large scale changes?
2) To deprecate driver because the maintainer is not responsible. Can
you please show me one example when that happened in the past?
I cannot show you an example because we never had to go that far and I
did not say that this is an established practice, but that we *could* do
that if we ever reached that point.
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.
This will have exactly 0. That is my point. Why to merge something
nobody will ever use?
Even if Alex and his firmware colleague end up being the only two people
using this driver if the decision is to make it upstream because this is
the desired distribution and development model of the driver we should
respect that.
And just to be clear, we should not be respecting that because Meta, or
Alex or anyone decided that they were doing the world a favor by working
in the open rather than being closed door, but simply because we cannot
*presume* about their intentions and the future.
For drivers specifically, yes, there is a question of to which degree
can we scale horizontally, and I do not think there is ever going to be
an answer to that, as we will continue to see new drivers emerge,
possibly with few users, for some definition of few.
--
Florian
