[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231128103304.25c2c642@kernel.org>
Date: Tue, 28 Nov 2023 10:33:04 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: David Ahern <dsahern@...nel.org>,
Saeed Mahameed <saeed@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arnd Bergmann <arnd@...db.de>,
Leon Romanovsky <leonro@...dia.com>,
Jiri Pirko <jiri@...dia.com>, Leonid Bloch <lbloch@...dia.com>,
Itay Avraham <itayavr@...dia.com>,
linux-kernel@...r.kernel.org, Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [PATCH V3 2/5] misc: mlx5ctl: Add mlx5ctl misc driver
On Tue, 28 Nov 2023 13:52:24 -0400 Jason Gunthorpe wrote:
> > The question at LPC was about making devlink params completely
> > transparent to the kernel. Basically added directly from FW.
> > That what I was not happy about.
>
> It is creating a back-porting nightmare for all the enterprise
> distributions.
We don't care about enterprise distros, Jason, or stable kernel APIs.
> > You can add as many params at the driver level as you want.
> > In fact I asked Saeed repeatedly to start posting all those
> > params instead of complaining.
>
> That really isn't what you said in the video.
>
> Regardless, configurables are only one part of what mlx5ctl addresses,
> we still have all the debugability problems, which are arguably more
> important.
Read-only debug interfaces are "do whatever you want" in netdev.
Params controlling them (ie. writing stuff) need to be reviewed
but are also allowed.
Doesn't mlx5 have a pile of stuff in debugfs already?
Nobody bothered to answer my "are you not going support mstreg over
this" question (arbitrary register writes).
> > Let the users complain about the user problems. Also something
> > I repeatedly told Saeed. His response was something along the lines
> > of users are secret, they can't post on the list, blah, blah.
>
> You mean like the S390 team at IBM did in the video?
>
> This is not a reasonable position. One of the jobs of the vendors is
> to aggregate the user requests. Even the giant hyperscale customers
> that do have the capacity to come on this list prefer to delegate
> these things to us.
>
> If you want to get a direct user forum the kernel mailing list is not
> an appropriate place to do it.
Agree to disagree.
> > You know one user who is participating in this thread?
> > *ME*
> > While the lot of you work for vendors.
>
> I'm sick of this vendor bashing. You work for *one* user. You know who
> talks to *every* user out there? *ME*.
>
> User and vendors need debugging of this complex HW. I don't need to
> bring a parade of a dozen users to this thread to re-enforce that
> obvious truth. Indeed when debugging is required the vendor usually
> has to do it, so we are the user in this discussion.
>
> You didn't answer the question, what is your alternative debug-ability
> vision here?
Covered above. And it's been discussed multiple times.
Honestly I don't want to spend any more time discussing this.
Once you're ready to work together in good faith let me know.
On future revisions of this series please carry:
Nacked-by: Jakub Kicinski <kuba@...nel.org>
Powered by blists - more mailing lists