Hi all, We recently got the request to backport the following commit to ovn24.03:
commit 4ed3b968ff9e88e2d1b675b74a0353de362a33bf Author: Lorenzo Bianconi <[email protected]> Date: Thu Sep 4 23:43:41 2025 +0200 northd: Introduce disable_garp_rarp option for logical_router table. Introduce disable_garp_rarp option in the Logical_Router table in order to disable GARP/RARP announcements by all the peer ports of this logical router. The main issue here is, in order to cleanly backport the patch to ovn24.03, we would need to add multiple intrusive commits like the ones below: commit 05527bd6ccdb1510fc3cb6b63c17b827cfaa4aee Author: Felix Huettner <[email protected]> Date: Tue Jun 10 14:03:50 2025 +0200 controller: Extract garp_rarp to engine node. Previously on each call to pinctrl_run all addresses that need to be announced via garps or rarps where computed newly. On larger external networks that might take significant time. However the content of the data can only change in a run of the I+P engine. So we move the whole logic to an engine node and only handle the minimal needed set in pinctrl_run. commit 05b99fb0cf4eb142fb3dd8fb1cd98cca3d68c716 Author: Mark Michelson <[email protected]> Date: Wed Aug 13 13:20:46 2025 -0400 en-datapath-logical-router: Incrementally process unsynced routers. All changes to northbound logical routers can be incrementally processed by en-datapath-logical-router. This change ensures that it is done and the changes can then be propagated to the next nodes. A new test in ovn-northd.at ensures the behavior. commit 7bb513bcfda380657efe2888b57dabcbd3544536 Author: Mark Michelson <[email protected]> Date: Wed Aug 13 13:20:45 2025 -0400 northd: Refactor datapath syncing. In current OVN, the en-northd node (via code in northd.c) takes full control of syncing logical switches and logical routers with southbound datapath bindings. This is fine, so long as: 1) These are the only datapath types to sync. 2) northd will always be the arbiter of datapath syncing. However, future commits will introduce new types of datapaths. These are not good fits for the en-northd node, since they have completely independent processing rules, and trying to shoehorn them into a struct ovn_datapath would be wasteful. This patch introduces a new way of syncing datapaths. Each datapath type has a node that is responsible for creating an ovn_unsynced_datapath_map for the type of datapath it creates. Then a type-agnostic datapath syncing node syncs these datapaths with the southbound Datapath_Binding type. Then, these synced datapaths are fed back into type-specific datapath nodes, which translate these synced datapaths into specific types. Nodes can then use these as inputs if they need synced datapaths (i.e. a northbound type with its corresponding southbound type). In this case, en_northd uses the synced logical switch and logical router types in order to create its ovn_datapath structures. Doing this will provide an easy way to sync new datapath types to the southbound database. I am wondering if it is ok to rework the feature implemented in 4ed3b968f with a specific patch for ovn24.03. What do you think/prefer? Thanks in advance. Regards, Lorenzo
_______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
