Re: [PATCH net-next] openvswitch: enable ops lock for internal ports

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 13 Aug 2026 19:55:27 +0200 Ilya Maximets wrote:
> On 8/13/26 9:40 AM, Wang Zhan wrote:
> >> Why are you sending this patch? Do you have an actual real life need
> >> for unlocked get_drvinfo??  
> > 
> > Yes. The use case is broader than unlocked get_drvinfo.
> > 
> > We are trying to reduce cases where ovs-vswitchd gets blocked waiting for
> > the global RTNL lock. In production we saw ovs-vswitchd repeatedly report
> > "Unreasonably long" poll intervals. Tracing showed one OVS operation waiting
> > about 500 ms for RTNL while node-exporter was collecting the speed of an
> > mlx5 interface. The node-exporter process was CPU quota throttled, which
> > stretched that RTNL hold time; mlx5 can make this easier to hit because some
> > queries go through firmware/mailbox paths.  
> 
> I'd say this is more indicative of the issues in other places, like mlx5
> driver.  IIRC, it can call synchronize_net under rtnl many times in a row
> causing any other application that needs rtnl to stall.  We've seen this
> behavior blocking OVS in ovn-kubernetes setups many times in the past few
> years and it needs to be addressed in the driver.

FWIW mlx5 slowness is in fact the reason for unlocked ethtool ops to
exist in the first place. So if that was the cause of initial backup
the problem may already be solved "at the source", so to speak.