On 3/12/26 11:12 PM, Lorenzo Bianconi via dev wrote: > Hi all, > Hi Lorenzo,
> 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. > If this is required and there's no other viable workaround for users I'm OK with backporting this feature. It seems like a low-risk change. > 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. > My preference would be towards a custom backport, to keep things as simple as possible (and low-risk as possible). Regards, Dumitru > Regards, > Lorenzo > > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
