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]
Date: Fri, 22 Mar 2024 13:58:26 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Andy Gospodarek <andrew.gospodarek@...adcom.com>
Cc: David Ahern <dsahern@...nel.org>, Greg Kroah-Hartman
 <gregkh@...uxfoundation.org>, Jason Gunthorpe <jgg@...dia.com>, Christoph
 Hellwig <hch@...radead.org>, Saeed Mahameed <saeed@...nel.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>, Saeed Mahameed <saeedm@...dia.com>, Aron Silverton
 <aron.silverton@...cle.com>, linux-kernel@...r.kernel.org,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver

On Fri, 22 Mar 2024 11:46:27 -0400 Andy Gospodarek wrote:
> > > It's the middle of the merge window, not much we can actually do and
> > > this patch series itself couldn't be applied as-is, so it's hard to see
> > > what could have happened on my end...
> > 
> > The proposal was sent a week before the end of the last development
> > cycle, and I believe the intent was to motivate discussion around a
> > concrete proposal to converge on an acceptable solution before sending
> > patches.
> > 
> > On your end, what would be helpful is either a simple yes this seems
> > reasonable or no you don't like it for reasons X, Y, and Z.
> 
> Well said, David.
> 
> I would totally support doing something like this in a fairly generic
> way that could be leveraged/instantiated by drivers that will allow
> communication/inspection of hardware blocks in the datapath.  There are
> lots of different ways this could go, so feedback on this would help get
> us all moving in the right direction.

The more I learn, the more I am convinced that the technical
justifications here are just smoke and mirrors. The main motivation
for nVidia, Broadcom, (and Enfabrica?) being to hide as much as
possible of what you consider your proprietary advantage in the 
"AI gold rush".

RDMA is what it is but I really hate how you're trying to pretend
that it's is somehow an inherent need of advanced technology and
we need to lower the openness standards for all of the kernel.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ