On Thu, Feb 13, 2025 at 3:52 PM Max Lamprecht via dev < [email protected]> wrote:
> We don't need to do a full lflow recompute for non_vif_data changes. > non_vif_data is only used to retrieve the local openflow port of an > OVN port that is currently bound to the chassis and this will never change. > > Signed-off-by: Max Lamprecht <[email protected]> > --- > Hi Max, thank you for the patch. However I don't agree with the conclusion. The ofport can actually change even after the port and interface are created. So this approach would mean that lflow referencing this ofport number would be wrong until the next recompute of the lflow. It is extremely rare that this would happen, maybe we could have handler which would check the ofport changes. Also what change in the non_vif triggers the recompute? CCing maintainers maybe the "risk" of having this bug is acceptable. > controller/ovn-controller.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c > index 194d2e2fe..d76067e30 100644 > --- a/controller/ovn-controller.c > +++ b/controller/ovn-controller.c > @@ -5354,8 +5354,10 @@ main(int argc, char *argv[]) > lflow_output_template_vars_handler); > engine_add_input(&en_lflow_output, &en_runtime_data, > lflow_output_runtime_data_handler); > + /* Using a noop handler because we only need the non_vif_data to find > + * the corresponding local openflow port of an OVN port. */ > engine_add_input(&en_lflow_output, &en_non_vif_data, > - NULL); > + engine_noop_handler); > > engine_add_input(&en_lflow_output, &en_sb_multicast_group, > lflow_output_sb_multicast_group_handler); > -- > 2.34.1 > > _______________________________________________ > 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
