On Wed, Nov 4, 2026 at 9:08 AM Jacob Tanenbaum <[email protected]> wrote: > I think this needs to be revalidated against the SB table. Consider a > next-hop that is removed while ofctrl is backlogged, > then re-added before ofctrl recovers. ecmp_nexthop_run() re-inserts it into > ecmp-nexthop, but the stale copy stays in > ecmp_nexthop_pending_flush. When ofctrl can send again the flush drops the > conntrack entries for a next-hop that is back in service. > > I think we have to drop pending entries when the same (next-hop, mac, > zone_id) tuple reappears in enh_table during exmp_nexthop_monitor_run(). > What do you think?
Thanks, Jacob, you are right. A flush only stays pending while the flows that remove the next-hop have not reached the switch either, so if the next-hop is back by then its conntrack entries are still valid and must not be flushed. v2 drops the pending entry when the same (next-hop, mac, zone_id) shows up again in ecmp_nexthop_monitor_run(). I kept the existing test steps and added the case you describe as a third step: remove the next-hop and add it back while ofctrl is still backlogged, then check that no flush reaches the switch. On v1 that step sees one extra flush; with the change it sees none. I will send v2 shortly. This reply was written with the help of an AI assistant (Claude Opus 5.5, Claude Code). Thanks, Bekei _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
