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]

Message-ID: <20230615123325.421ec9aa@kernel.org>
Date: Thu, 15 Jun 2023 12:33:25 -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, 15 Jun 2023 19:37:23 +0200 Jiri Pirko wrote:
> Thu, Jun 15, 2023 at 06:37:01PM CEST, kuba@...nel.org wrote:
> >On Thu, 15 Jun 2023 12:51:09 +0200 Jiri Pirko wrote:  
> >> The problem is scalability. SFs could be activated in parallel, but the
> >> cmd that is doing that holds devlink instance lock. That serializes it.
> >> So we need to either:
> >> 1) change the devlink locking to be able to execute some of the cmds in
> >>    parallel and leave the activation sync
> >> 2) change the activation to be async and work with notifications
> >> 
> >> I like 2) better, as the 1) maze we just got out of recently :)
> >> WDYT?  
> >
> >I guess we don't need to wait for the full activation. Is the port
> >creation also async, then, or just the SF devlink instance creation?  
> 
> I'm not sure I follow :/
> The activation is when the SF auxiliary device is created. The driver then
> probes the SF auxiliary device and instantiates everything, SF devlink,
> SF netdev, etc.

Sorry, maybe let's look at an example:

$ devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 11

needs to print / return the handle of the created port.

$ devlink port function set pci/0000:08:00.0/32768 \
               hw_addr 00:00:00:00:00:11 state active

needs to print / return the handle of the devlink instance

> We need wait/notification for 2 reasons
> 1) to get the auxiliary device name for the activated
>    SF. It is needed for convenience of the orchestration tools.
> 2) to get the result of the activation (success/fail)
>    It is also needed for convenience of the orchestration tools.

Are you saying the activation already waits for the devlink instance to
be spawned? If so that's great, all we need to do is for the:

$ devlink port function set pci/0000:08:00.0/32768 \
               hw_addr 00:00:00:00:00:11 state active

to either return sufficient info for the orchestration to know what the
resulting SF / SF devlink instance is. Most likely indirectly by adding
that info to the port so that the PORT_NEW notification carries it.

Did I confuse things even more?

As a reminder what sparked this convo is that user specifies "sfnum 11"
in the example, and the sf device gets called "sf.1".