linux-kernel - Re: mlx5 ConnectX diagnostic misc driver

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:   Thu, 19 Oct 2023 13:50:55 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Saeed Mahameed <saeedm@...dia.com>,
        Leon Romanovsky <leonro@...dia.com>,
        Jiri Pirko <jiri@...dia.com>, linux-kernel@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: mlx5 ConnectX diagnostic misc driver

On Thu, Oct 19, 2023 at 09:23:46AM -0700, Jakub Kicinski wrote:
> On Thu, 19 Oct 2023 13:01:45 -0300 Jason Gunthorpe wrote:
> > Do you have a lore link?
> 
> No, it was pitched at conferences:
> 
> Last year's LPC: https://www.youtube.com/watch?v=JGR9ZCeiW-E
> This year's netconf / KR, but Saeed didn't have slides:
> https://netdev.bots.linux.dev/netconf/2023/index.html
> 
> Really, you should be asking Saeed this, not me.

You brought it up. I was at that LPC talk, and you made it clear not
to even propose using devlink. Seems like that is what Saeed did to
me.

> > Looking at Saeed's tool capability on his github it is significantly,
> > but not exclusively supporting RDMA (ie drivers/infiniband), with some
> > features for the mlx5 VFIO drivers, mlx5 VDPA and a bunch of lowlevel
> > PCI stuff too.
> > 
> > Calling it a "networking device" in the sense of "it is owned only be
> > netdev" is not accurate.
> 
> Yes, let's now have a pointless augment about when a NIC is a NIC
> and when it's no longer a NIC because it has offloads.

This is not a pointless argument. How mlx5 hardware works in the many
subsystems it works with is NOT your exclusive decision to dictate
just because it has a shared networking port on the back of the card.

Lets focus on a community conensus approach between all the subsystems
please. If you have a better suggestion how to address this
cross-subsystem need then please share it.

> My point is Saeed pitched this to networking maintainers *twice*

I read that as for a devlink version, this is clearly not devlink.

> My point is Saeed pitched this to networking maintainers *twice*
> and then purposefully left us out of the CC list.
> That is absolutely unacceptable IMO, but I'd like to consult with
> others to make sure it's not just me. Please allow me some time
> to do that.

It is standard practice not to CC'd netdev for mlx5 related work
outside the scope of the netdev driver.

Jason