Date: Thu, 4 Apr 2024 07:48:50 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: David Ahern <dsahern@...nel.org>, Leon Romanovsky <leon@...nel.org>,
 Edward Cree <ecree.xilinx@...il.com>, Greg Kroah-Hartman
 <gregkh@...uxfoundation.org>, Christoph Hellwig <hch@...radead.org>, Saeed
 Mahameed <saeed@...nel.org>, Arnd Bergmann <arnd@...db.de>, Jiri Pirko
 <jiri@...dia.com>, Leonid Bloch <lbloch@...dia.com>, Itay Avraham
 <itayavr@...dia.com>, Saeed Mahameed <saeedm@...dia.com>, Aron Silverton
 <aron.silverton@...cle.com>, linux-kernel@...r.kernel.org,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Andy Gospodarek
 <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver

On Thu, 4 Apr 2024 09:23:38 -0300 Jason Gunthorpe wrote:
> > "didn't understand the discussion" is an ironic thing for you to +1,
> > David. After all my emails about HNS3 RDMA you somehow concluded today
> > that I want to make rules for the entire kernel:
> > https://lore.kernel.org/all/6faa47b0-27c3-47f9-94be-1ec671d9543c@kernel.org/  
> 
> What if (hypothetically) I tould you that the congestion control
> settings in the device FW impacted netdev sourced ethernet trafic as
> well? Would you be so sanguine that RDMA should have those settings?

We can lawyer the words until the cows come home.
The team I work on takes care of both RoCE/IB/pick your fav proto
and TCP/IP NICs. It's fairly obvious what is RoCE and what is TCP
or user UDP when there are no incentives to act otherwise :|

> > And I second what Ed said. I have asked multiple vendors preaching
> > impossibilism in this thread to start posting those knobs. I offered
> > to do a quick off-list review of the list of knobs they have to give 
> > a quick yay / nay, so they don't waste time implementing things that
> > would get nacked. None of the vendors bothered taking me up on that
> > offer.  
> 
> As far as configuration/provisioning goes, it is really all or
> nothing.
> 
> If a specific site can configure only 90% of the stuff required
> because you will NAK the missing 10% it then it is still not usable
> and is a wasted effort for everyone.

(a) are you saying that the device needs 100% of the knobs to be used?
    oof, you better warn your prospective customers :S
(b) as Ed pointed out some of the "knobs" are just hacks and lazy
    workarounds so we rejected them for quality reasons; the remaining
    rejects are because the knobs aren't really device specific, but
    vendors don't want to extend existing APIs, as it is easier to
    ship "features" without having a core kernel dependency...

> You have never shown that there is a path to 100% with your approach
> to devlink. In fact I believe you've said flat out that 100% is not
> achievable. Right here you illustrate the fundamental problem again:
> there are configurables that already exist in the device that you will
> NAK for devlink.
> 
> This is fundamentally why no one is taking you up on these generous
> offers to pre-NAK device's designs. You made it explicit that you will
> will NAK something and then it is not 100%.
> 
> Saeed has said repeatedly he wants 100% of the endless configurables
> in mlx5. You have the manual and know what they are, tell him how to
> get to 100% in a few months of work and I will believe you that it is
> not impossible.

Sorry, are you saying that I'm responsible for a providing a solution
to allow arbitrary vendor tools to work and proprietary user space to
communicate directly with the proprietary firmware?

> Then we only have fwctl's support for debugging and other topics to
> argue about :P

Powered by blists - more mailing lists