On Tue, Mar 17, 2026 at 4:08 PM Dumitru Ceara via dev < [email protected]> wrote:
> 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). > +1, the bare minimum of changes to keep the option working. > > 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 > > Thanks, Ales _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
