On Tue, 3 Mar 2026 at 22:42, Ilya Maximets <[email protected]> wrote:
> Hrm. I think, the right solution is to not call this function at all > for ports attached to the userspace datapath. For these ports the > vport netlink request makes no sense. It is already working this way > for tap devices - the nsid is unconditionally set to local for them > in the netdev_linux_netnsid_update(). But until "recently" there was > no way to tell if the other types of netdevs belong to the kernel > datapath or to the userspace one. But we can today. We could change > the tap class check to netdev_get_dpif_type(netdev) comparison with > the string "system", if the type is set. "system" means kernel datapath, > any other type will not work with the netlink vport lookup. > > Best regards, Ilya Maximets. Hi Ilya, Thank you for the review. I have just sent a revised patch series. And thank you also for the tip on this, I have followed your suggestion in the revision. I have encountered two hurdles while implementing the check in this way, though. One is that I could not replace the netdev_get_class(&netdev->up) == &netdev_tap_class check since I noticed that filling dpif_type is explicitly skipped in dpif_port_add() for tap ports, so I cannot really safely check if its value is "system". I could have generalized and call netnsid_set_local() even if the dpif_type is NULL, but I saw some possible issues with this and I preferred to keep the TAP condition explicit. The second one is that there was a mismatch between the netns that local RTM events carry (kernel-assigned nsid) and the statically set local netnsid, so I had to add a bypass in netdev_linux_update() to avoid dropping the events in case of "system" dpif (I added a better explanation to the commit message and as a comment before the check happens). Let me know what you think about this (it might be too loose of a condition, but I cannot think of a counterpoint). Best Regards, Matteo _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
