Hi Ales, On 6/19/26 11:29 AM, Dumitru Ceara wrote: > On 6/19/26 10:43 AM, Ales Musil via dev wrote: >> The multicast groups were updated as part of the lflow handler >> which is wrong. There is multicast group node which takes >> care of the group updates. Also, the updates in the lflow handler >> were partially wrong and not in line with the multicast group >> node. >> >> At the same time remove the lsp_can_receive_multicast() check that >> would prevent the lflow creation for new LSPs. >> >> Reported-at: https://redhat.atlassian.net/browse/FDP-4022 >> Assisted-by: Claude Opus 4.6, Claude Code >> Fixes: b741cb7e299c ("northd: Incremental processing of VIF updates and >> deletions in 'lflow' node.") >> Fixes: 8e2d6fa14804 ("northd, tests: Network Function insertion logical flow >> programming.") >> Signed-off-by: Ales Musil <[email protected]> >> --- > > Hi Ales, > > Thanks for the patch! > >> northd/en-multicast.c | 7 +++- >> northd/northd.c | 41 ------------------ >> tests/ovn-northd.at | 96 +++++++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 101 insertions(+), 43 deletions(-) >> >> diff --git a/northd/en-multicast.c b/northd/en-multicast.c >> index b2775516a..5148d8840 100644 >> --- a/northd/en-multicast.c >> +++ b/northd/en-multicast.c >> @@ -153,7 +153,10 @@ multicast_igmp_northd_handler(struct engine_node *node, >> void *data OVS_UNUSED) >> return EN_UNHANDLED; >> } >> >> - if (hmapx_count(&northd_data->trk_data.trk_switches.deleted)) { >> + struct tracked_ovn_ports *trk_lsps = &northd_data->trk_data.trk_lsps; >> + if (hmapx_count(&trk_lsps->created) || >> + hmapx_count(&trk_lsps->updated) || >> + hmapx_count(&trk_lsps->deleted)) { >> return EN_UNHANDLED; > > This will cause the en_multicast_igmp node to recompute every time we > add/update/delete a logical switch port. Which will trigger the > lflow_multicast_igmp_handler incremental handler for the en_lflow node. > > While that handler's work in theory isn't too heavy weight, it does > recompute all multicast related lflows for all switch ports in the NB. > > Just to be sure, I'd like to hold on with accepting this change until we > manage to test it downstream in some of the scale testing setups we have > right now. I cc-ed Patryk in case he has some time to help with that. >
Patryk confirmed internally (thanks Patryk for testing!) that this change doesn't significantly affect control plane performance in the scenario I was worried about. The code itself looks good to me: Acked-by: Dumitru Ceara <[email protected]> Thanks, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
