On 23 Jan 16:55, Jakub Kicinski wrote:

On Thu, 23 Jan 2025 16:39:05 -0800 Stanislav Fomichev wrote:

quoted

quoted

quoted

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.

Are you expecting drivers to hold netdev_lock internally? 
I was thinking something more scalable, queue_mgmt API to take
netdev_lock,  and any other place in the stack that can access 
"netdev queue config" e.g ethtool/netlink/netdev_ops should grab 
netdev_lock as well, this is better for the future when we want to 
reduce rtnl usage in the stack to protect single netdev ops where
netdev_lock will be sufficient, otherwise you will have to wait for ALL
drivers to properly use netdev_lock internally to even start thinking of
getting rid of rtnl from some parts of the core stack.