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]
Message-ID: <20250207073648.1f0bad47@kernel.org>
Date: Fri, 7 Feb 2025 07:36:48 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Andy Gospodarek <andrew.gospodarek@...adcom.com>
Cc: Jason Gunthorpe <jgg@...dia.com>, Aron Silverton
 <aron.silverton@...cle.com>, Dan Williams <dan.j.williams@...el.com>,
 Daniel Vetter <daniel.vetter@...ll.ch>, Dave Jiang <dave.jiang@...el.com>,
 David Ahern <dsahern@...nel.org>, Andy Gospodarek <gospo@...adcom.com>,
 Christoph Hellwig <hch@...radead.org>, Itay Avraham <itayavr@...dia.com>,
 Jiri Pirko <jiri@...dia.com>, Jonathan Cameron
 <Jonathan.Cameron@...wei.com>, Leonid Bloch <lbloch@...dia.com>, Leon
 Romanovsky <leonro@...dia.com>, linux-cxl@...r.kernel.org,
 linux-rdma@...r.kernel.org, netdev@...r.kernel.org, Saeed Mahameed
 <saeedm@...dia.com>, "Nelson, Shannon" <shannon.nelson@....com>, Michael
 Chan <michael.chan@...adcom.com>
Subject: Re: [PATCH v4 10/10] bnxt: Create an auxiliary device for
 fwctl_bnxt

On Thu, 6 Feb 2025 22:17:58 -0500 Andy Gospodarek wrote:
> On Thu, Feb 6, 2025 at 7:44 PM Jakub Kicinski <kuba@...nel.org> wrote:
> > On Thu,  6 Feb 2025 20:13:32 -0400 Jason Gunthorpe wrote:  
> > > From: Andy Gospodarek <gospo@...adcom.com>
> > >
> > > Signed-off-by: Andy Gospodarek <gospo@...adcom.com>
> > > Signed-off-by: Jason Gunthorpe <jgg@...dia.com>  
> >
> > This is only needed for RDMA, why can't you make this part of bnxt_re ?  
> 
> This is not just needed for RDMA, so having the aux device for fwctl
> as part of the base driver is preferred.

Please elaborate. As you well know I have experience using Broadcom
devices in large TCP/IP networks, without the need for proprietary
tooling.

Now, I understand that it may be expedient for Broadcom and nVidia
to skip the upstream process and ship "features" to customers using
DOCA and whatever you call your tooling. But let's be honest that 
this is the motivation here. Unified support for proprietary tooling
across subsystems and product lines for a given vendor. This way
migrating from in-tree networking to proprietary IPU/DPU networking
is easier, while migrating to another vendor would require full tooling
replacement.

I have nothing against RDMA and CXL subsystems adding whatever APIs
they want. But I don't understand why you think it's okay to force 
this on normal networking, which does not need it.

nVidia is already refusing to add basic minoring features to their
upstream driver, and keeps asking its customers to migrate to libdoca.
So the concern that merging this will negatively impact standard
tooling is no longer theoretical.

Anyway, rant over. Give us some technical details.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ