On Tue, Aug 25, 2026 at 3:38 PM Dumitru Ceara <[email protected]> wrote:
> On 8/25/26 3:36 PM, Ales Musil wrote: > > > > > > On Tue, Aug 25, 2026 at 3:34 PM Dumitru Ceara <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 8/25/26 3:28 PM, Ales Musil wrote: > > >>> +void > > >>> +evpn_mac_binding_sync_run( > > >>> + struct ovsdb_idl_txn *ovnsb_idl_txn, > > >>> + struct ovsdb_idl_index *sbrec_mac_binding_by_lport_ip, > > >>> + const struct sbrec_mac_binding_table *mb_table, > > >>> + const struct hmap *local_datapaths, > > >>> + const struct hmap *evpn_arps, > > >>> + struct mac_cache_data *mac_cache_data, > > >>> + struct ed_type_evpn_mac_binding_sync *data, > > >>> + struct evpn_mb_sync_waker *waker) > > >>> +{ > > >>> + if (!ovnsb_idl_txn) { > > >>> + data->sb_changes_pending = true; > > >> Isn't this a bit too conservative? We might not have any pending > > >> changes, right? Should we delay setting data->sb_changes_pending > > until > > >> we actually need to update the SB somewhere later in this > function? > > >> > > > So I had a design that actually deffered the sb_changed_pending > > > for later, but it turned out to be a mess. So I have decided to > make > > > it easier. Let me know if I should invest time in trying to come up > > > with better solution. > > > > I guess that's probably fine. > > > > Let's leave it as is. > > > > Regards, > > Dumitru > > > > > > Can I add your ack to this patch then after addressing the other > > minor comments? > > > > Yes, that's fair, I guess we don't need a v2 then. > > Acked-by: Dumitru Ceara <[email protected]> > > Regards, > Dumitru > > > Regards, > > Ales > > Thank you Dumitru, applied to main and backported down to 26.03 with the nits fixed. Regards, Ales _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
