On Thu, 13 Aug 2026 19:55:27 +0200 Ilya Maximets wrote: > 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.
Right. As Jakub pointed out, mlx5 slowness was one of the reasons for introducing unlocked ethtool operations. However, netdev sysfs operations can still invoke driver callbacks while holding RTNL on current upstream, so contention from slow callbacks has not been fully removed. I agree that long RTNL holds should ultimately be addressed at their source. > 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. userspace-tso-enable is a global setting. Kernel and userspace datapaths can coexist in the same ovs-vswitchd. In this setup, enabling it for the userspace datapath also causes netdev_linux_construct() to probe ports belonging to the kernel datapath, including internal ports. This is what the current code does and is the path we observed. As a side note, perhaps this probing should be limited to ports used by the userspace datapath? > 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. I agree that it is not the primary fix for long RTNL holds. I had treated this as a straightforward conversion to per-netdev ops locking. If this conversion is not considered worthwhile on its own, I'm fine with dropping the patch. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
