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.

While we could avoid rtnl here, it won't save us in other operations that
do require rtnl.

> netdev_linux_set_ol() is one OVS path that can take RTNL. With
> userspace-tso-enable, OVS uses this path to read ethtool feature information
> through ETHTOOL_GSSET_INFO, ETHTOOL_GSTRINGS and ETHTOOL_GFEATURES. For
> ovs-internal-port, these GET operations do not need RTNL, but currently take
> it because internal ports do not opt into per-device ops locking.

This doesn't sound right.  netdev_linux_set_ol() is only called if userspace
TSO is enabled, and that doesn't make much sense for the kernel datapath.
But also, userspace datapath doesn't create internal type devices, it creates
tap devices instead.  So, it doesn't look like a real use case, unless I'm
missing something.

All in all, the change itself may be fine, but I'm not sure it actually helps
with anything in a grand scheme of things.

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to