Re: [net-next 10/11] net/mlx5e: Implement queue mgmt ops and single channel swap

Jakub Kicinski
2025-01-24T00:55:54Z

On Thu, 23 Jan 2025 16:39:05 -0800 Stanislav Fomichev wrote:
> > > What technical debt accrued ? I haven't seen any changes in queue API since
> > > bnxt and gve got merged, what changed since then ?
> > >
> > > mlx5 doesn't require rtnl if this is because of the assert, I can remove
> > > it. I don't understand what this series is being deferred for, please
> > > elaborate, what do I need to do to get it accepted ?
> >
> > Remove the dependency on rtnl_lock _in the core kernel_.
>
> IIUC, we want queue API to move away from rtnl and use only (new) netdev
> lock. Otherwise, removing this dependency in the future might be
> complicated.

Correct. We only have one driver now which reportedly works (gve).
Let's pull queues under optional netdev_lock protection.
Then we can use queue mgmt op support as a carrot for drivers
to convert / test the netdev_lock protection... "compliance".

I added netdev_lock protection for NAPI before the merge window.
Queues are configured in much more ad-hoc fashion, so I think
the best way to make queue changes netdev_lock safe would be to
wrap all driver ops which are currently under rtnl_lock with
netdev_lock.