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 08:42:38 +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

Wed, Jun 21, 2023 at 08:23:53PM CEST, kuba@...nel.org wrote:
>On Wed, 21 Jun 2023 15:14:35 +0200 Jiri Pirko wrote:
>>> Did I confuse things even more?  
>> 
>> No, no confusion. But, the problem with this is that devlink port function set
>> active blocks until the activation is done holding the devlink instance
>> lock. That prevents other ports from being activated in parallel. From
>> driver/FW/HW perspective, we can do that.
>> 
>> So the question is, how to allow this parallelism?
>
>You seem to be concerned about parallelism, maybe you can share some
>details / data / calculations? I don't think that we need to hold 
>the instance lock just to get the notification but I'd strongly prefer
>not to complicate things until problem actually exists.
>
>The recent problems in the rtnl-lock-less flower implementation made me
>very cautious about complicating the stack because someone's FW is slow.

I agree 100%. That is my stand as well. Lock less devlink commands
are a simple no-go from my perspective. We got out of that mess only
recently.

I just checked mlx5 code, the SF activation does not block. It just
triggers activation of SF in FW and returns. Does not wait for
completion.

Let me figure out the devlink_port<->sf_devlink linkage and I believe
that would be enough for all needed usecases.