Re: [RFT net-next 0/6] devlink: expose instance locking and simplify port splitting

[Leon Romanovsky <leonro@nvidia.com>]

On Tue, Mar 15, 2022 at 08:58:29AM -0700, Jakub Kicinski wrote:
> On Tue, 15 Mar 2022 09:39:31 +0200 Leon Romanovsky wrote:
> > > I have the eswitch mode conversion patches almost ready with the
> > > "almost" being mlx5.   
> > 
> > I wonder why do you need to change eswitch locking in mlx5?
> 
> I want DEVLINK_CMD_ESWITCH_SET to drop the DEVLINK_NL_FLAG_NO_LOCK
> marking.

+1

> 
> Other drivers are rather simple in terms of locking (bnxt, nfp,
> netdevsim) and I can replace driver locking completely with a few 
> minor changes. Other drivers have no locking (insert cry/laugh emoji).

I saw it too :)

> 
> mlx5 has layers and multiple locks, 

I would say that mlx5 has too many locks.

> if you're okay with devl_unlock() / devl_lock() inside the callback that's perfect for me.

The need of DEVLINK_NL_FLAG_NO_LOCK for eswitch is because of
questionable locking in devlink_rate_*() calls. 

If you success to remove mutex_lock from devlink_rate_nodes_check()
and devlink_rate_nodes_destroy(), you won't need devl_unlock/devl_lock
for eswitch.

Right now, the eswitch set flow doesn't suffer from races and/or other
bugs, just because of global devlink_mutex that protects unlocked parts
of devlink_nl_cmd_eswitch_set_doit().

Thanks