Thank you Ales and Ilya for your reviews! I am in the process of reworking this PR to use the OVS infrastructure already in-place.
I was almost ready to post the patch for the OVS side but Ilya raised a good concern today. So, I integrated the situation illustrated (a veth pair is removed and then recreated with the same name) in a test case and, in fact, it causes issues with stale values. I am trying to work out how to tackle this situation. With kernel datapath is trivial, but in userspace we do not receive RTM_NEWLINK/RTM_DELLINK to invalidate VALID_DRVINFO (and, consequently, retrigger fetching the peer ifindex) when the device is recreated. I tried various solutions but the only one that worked was checking if the veth ifindex changes. Although calling get_ifindex() is an ioctl and not a call to ethtool, it still does introduce scalability problems, so it is best to avoid it. I want to try and see if I find some other way to handle this, but I will still post the basic code as an RFC tomorrow if I do not get any worthwhile ideas, so we can discuss it with more context. Thank you for all the help. Best Regards, Matteo On Tue, 20 Jan 2026 at 21:17, Ilya Maximets <[email protected]> wrote: > On 1/20/26 9:08 PM, Ilya Maximets wrote: > > On 1/19/26 8:04 AM, Ales Musil wrote: > >> > >> > >> On Fri, Dec 19, 2025 at 12:33 PM Matteo Perin via dev < > [email protected] <mailto:[email protected]>> wrote: > >> > >> The OVN native route learning code added the LRP > dynamic-routing-port-name > >> and accompanying dynamic-routing-port-mapping key in the local OVS > table. > >> > >> When the routing-protocol-redirect option is in use on an LRP, the > need to > >> manually set the dynamic-routing-port-name and > dynamic-routing-port-mapping > >> options can be removed if OVN can support looking up the veth pair > bound to > >> the LSP referred to, when using veth pairs to connect routing > daemons to OVN. > >> > >> This commit introduces this capability: when the > routing-protocol-redirect > >> option is configured on a LRP to redirect routing protocol traffic > to a LSP, > >> and that LSP is bound to a veth interface, ovn-controller will now > automatically > >> discover the peer interface name and uses it for dynamic route > learning. > >> > >> The discovery happens at port binding time in the route exchange > code path. > >> To do this, the ethtool ioctl interface is leveraged to verify the > bound > >> interface is a veth and, in that case, retrieve the peer ifindex > and relative > >> iface name. > >> This means that the discovery feature will only be available on > Linux platforms. > >> Also, there is a fallback to learning from all interfaces (base > case) if > >> discovery fails for any reason. > >> > >> This will simplify dynamic routing deployments by automating the > interface > >> mapping configuration that was previously required for veth-based > routing > >> daemon integrations. > >> > >> Signed-off-by: Matteo Perin <[email protected] <mailto: > [email protected]>> > >> --- > >> First of all, sorry everyone for the spam of emails I sent to > forward this > >> patch, since this is my first contribution attempt I am still > finding my > >> way around the project patch proposal pipeline. > >> > >> This addition to the OVN controller is an effort to remove the need > of > >> additional configuration when using the routing-protocol-redirect > with > >> one of the most common network setups used along routing daemons. > >> > >> The veth peer discovery is currently made thought an ioctl to > ethtool and > >> this, unfortunately, makes this added feature platfom-dependent. > >> As an alternative, I also though about moving the discovery part to > OVS > >> (this will not remove the linux kernel dependency, but it will make > it > >> part of the already in-place OVS linux netdev layer). > >> I did not go through with this idea since it seemed to require > moving too > >> many things around and adding space to store peer information to the > >> Interface table in OVSDB, and this seemed way too overkill for the > limited > >> scope of this feature. > >> > >> By my initial investigation, the refactoring using this approach > would require: > >> - Extending OVS rtnetlink support to parse IFLA_LINK attribute > (containing > >> veth peer ifindex info). > >> - Exposing it via OVSDB Interface:external_ids:peer_ifindex, or > similar > >> - OVN controller then reads peer info from OVS table and calls > if_indextoname() > >> to get interface name. > >> > >> Would this (more "disruptive") technique be more preferable than > having the > >> discovery management in a very specific path in the OVN controller? > If so, > >> I can rework the patch taking into account your suggestions. > >> > >> > >> Hello Matteo, > >> > >> thank you for the patch. I'm sorry I didn't reply earlier. To me it > seems > >> like it would be better to utilize what ovs already has. If you take a > look > >> at the way how "status" column is populated, we already call ethtool > >> there so it would be that hard to call it twice once with > "ETHTOOL_GDRVINFO" > >> which ovs already does, then with "ETHTOOL_GSTATS". Then we could > >> add the "peer_ifindex" into the "status". This is part of > "netdev_linux_get_status()". > >> Having that we could easily check the status column, does that sound > reasonable > >> to you? > >> > >> One note about "ETHTOOL_GSTATS" the hardcoded value 21 for the array > >> is not correct. It should be allocated to whatever the > "ETHTOOL_GDRVINFO" > >> returns in "n_stats". > >> > >> Ccing Ilya if he has any objections or other idea how to extend ovs > capabilities. > > > > We can do that from OVS side. But we need to be careful to avoid issuing > > the commands unnecessarily, i.e. we need to cache the results to avoid > > blocking inside the kernel when we have a lot of ports. But it's not > fully > > clear to me, how we would detect that the value changed in the kernel. > > This can potentially happen when the peer is moved in and out a different > > namespace. It's hard to keep this information up to date. Any ideas? > > Ah, nevermind. ifindex doesn't change, so we can just check it once. But > we need to make sure that we're not reporting a stale value if the > interface > is removed and then a new one is added with the same name. > > Best regards, Ilya Maximets. > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
