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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZJVlbmR9bJknznPM@nanopsycho>
Date: Fri, 23 Jun 2023 11:27:10 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
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

Thu, Jun 22, 2023 at 06:35:23PM CEST, kuba@...nel.org wrote:
>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

Yeah, the driver is assigning the auxdev id. I'm now trying to figure
out how to pass that to devlink code/user nicely. The devlink instance
for the SF does not exist yet, but we know what the handle is going to
be. Perhaps some sort of place holder instance would do. IDK.


>add some form of UUID on both the port and the sf devlink instance?

What about the MAC?

$ sudo devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 102
pci/0000:08:00.0/32769: type eth netdev eth8 flavour pcisf controller 0 pfnum 0 sfnum 102 splittable false
  function:
    hw_addr 00:00:00:00:00:00 state inactive opstate detached
$ sudo devlink port function set pci/0000:08:00.0/32769 hw_addr AA:22:33:44:55:66
$ sudo devlink port function set pci/0000:08:00.0/32769 state active
$ ip link show eth9
15: eth9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether aa:22:33:44:55:66 brd ff:ff:ff:ff:ff:ff

There are 2 issues with this:
1) If the hw_addr stays zeroed for activation, random MAC is generated
2) On the SF side, the MAC is only seen for netdev. That is problematic
   for SFs without netdev. However, I don't see why we cannot add
   devlink port attr to expose hw_addr on the SF.


>Maybe there's already some UUID in the vfio world we can co-opt?

Let me check that out.