On Thu, Aug 27, 2026 at 12:05 AM Dumitru Ceara <[email protected]> wrote: > > On 8/27/26 7:41 AM, Han Zhou wrote: > > Routing daemons commonly describe the next hop of a route with a separate > > kernel nexthop object that the route refers to by id, and ask the kernel to > > report nothing but that id. ovn-controller learned nothing from such > > routes. This series resolves the id against the kernel nexthop table, which > > the 'nexthop_exchange' node already maintains for EVPN, and keeps the routes > > learned from it up to date as the nexthop objects change. > > > > Route learning is then made incremental: a route or nexthop notification is > > applied to what was previously read from the table, instead of reading all > > watched tables again. With 10000 routes in one table a notification costs > > 25 ms where it used to cost 92 ms. > > > > Hi Han, > > Thanks for working on this! > > > Patch 1 and patch 4 fix pre-existing bugs found on the way. > > > > Patch 2 needs the OVS side to parse RTA_NH_ID, posted as "route-table: > > Support routes resolving through a nexthop object.". The submodule bump is > > left out until that is merged. > > > > Han Zhou (7): > > controller: Fix use-after-free of nexthop group members. > > controller: Learn routes referencing a kernel nexthop object. > > controller: Only relearn routes when a nexthop they use changes. > > controller: Resync netlink tables after missed notifications. > > controller: Keep the content of route notifications. > > controller: Split route learning into reading and resolving. > > controller: Learn routes incrementally. > > As you're kind of doing a few different things in this patch set (fixes > + incremental learning and support for learning routes with nexthop > objects) I was wondering if it would make sense to reorder the patches > and post the first part as non-RFC including: > > - fixes > - incremental learning support > > Then the second part, the RFC one, would be just essentially what you > have in patch 2 now which depends on the OVS patch. > > What do you think?
Thanks for the review! Makes sense, I will respin it that way. It is not quite a reorder though, the incremental patches carry a few nexthop specific bits that have to move to the second part: - the nhid field of 'struct ovn_route_msg', which comes from the OVS side, - the nexthop arguments of re_nl_resolve_route(), - the per table set of referenced nexthop ids together with route_exchange_handle_nexthop_changes(). The first part then becomes the two fixes, the route notification content, the read/resolve split and incremental learning driven by route notifications only, none of which needs the OVS patch. The second part ends up as two patches rather than one: learning a route through a nexthop id, and handling nexthop changes incrementally. "controller: Only relearn routes when a nexthop they use changes." merges into the former, since on top of the incremental infrastructure there is no longer an intermediate step that recomputes route_exchange on every nexthop change. So the split makes that part smaller as well. The numbers in "controller: Learn routes incrementally." were measured with routes using nexthop ids, which needs the OVS patch, so I will measure them again with plain routes for the first part. Thanks, Han > > Regards, > Dumitru > > > > > .../topics/dynamic-routing/architecture.rst | 27 +- > > NEWS | 5 + > > controller/nexthop-exchange.c | 60 +-- > > controller/nexthop-exchange.h | 56 +++ > > controller/ovn-controller.c | 320 ++++++++++--- > > controller/ovn-netlink-notifier.c | 60 ++- > > controller/ovn-netlink-notifier.h | 1 + > > controller/route-exchange-netlink.c | 312 +++++++++++-- > > controller/route-exchange-netlink.h | 65 ++- > > controller/route-exchange.c | 420 +++++++++++++++--- > > controller/route-exchange.h | 37 +- > > tests/ovn-inc-proc-graph-dump.at | 3 +- > > tests/system-ovn-netlink.at | 234 +++++++++- > > tests/system-ovn.at | 77 ++++ > > tests/test-ovn-netlink.c | 213 ++++++++- > > 15 files changed, 1665 insertions(+), 225 deletions(-) > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
