netdev - Re: [net-next 14/15] net/mlx5: Light probe local SFs

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, 22 Jun 2023 09:35:23 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Saeed Mahameed <saeed@...nel.org>, Saeed Mahameed <saeedm@...dia.com>,
 "David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org, Tariq Toukan
 <tariqt@...dia.com>, Shay Drory <shayd@...dia.com>, Moshe Shemesh
 <moshe@...dia.com>
Subject: Re: [net-next 14/15] net/mlx5: Light probe local SFs

On Thu, 22 Jun 2023 08:38:05 +0200 Jiri Pirko wrote:
> I checked, the misalignment between sfnum and auxdev index.
> The problem is that the index space of sfnum is per-devlink instance,
> however the index space of auxdev is per module name.
> So if you have one devlink instance managing eswitch, in theory we can
> map sfnum to auxdev id 1:1. But if you plug-in another physical nic,
> second devlink instance managing eswitch appears, then we have an
> overlap. I don't see any way out of this, do you?
> 
> But, I believe if we add a proper reference between devlink sf port and
> the actual sf devlink instace, that would be enough.

SG. For the IPU case when spawning from within the IPU can we still
figure out what the auxdev id is going to be? If not maybe we should
add some form of UUID on both the port and the sf devlink instance?
Maybe there's already some UUID in the vfio world we can co-opt?