Expression parsing code in ovn-controller depends on the logical datapath. This is because of optimization made for BZ 1818128: https://github.com/ovn-org/ovn/commit/bff01d49d6f27424a2bef197ef50bae8b03cbd00 Parser reconstructs the name of a port group using the datapath tunnel key. This makes it really hard to implement solution for BZ 1877002, because expression parsing requires 1:1 lfow to logical datapath relation. Need to remove this dependency from expression parsing code to unblock BZ 1877002 and actually untangle the code, i.e. make it cleaner and better logically separated.
Ilya, is this bug still relevant now that bug 1877002 is finished?
(In reply to Dan Williams from comment #1) > Ilya, is this bug still relevant now that bug 1877002 is finished? I think it still is. Right now we reparse the complete match/action expression for each logical datapath in the datapath group. We can optimize lflow processing in ovn-controller by: 1. pre-parsing the match and action expressions regardless of logical datapath/datapath group the flow is applied to. 2. In a second step we can refine the pre-parsed expression for each logical datapath in the lflow's datapath group.
I'm going to echo Dan's question from last year and ask if this is still relevant. I suppose that the optimization potential may still exist, but the bigger question is whether it's worth pursuing. We're in a different position than we were 2 years ago with regards to OVN performance. These days, ovn-controller is typically not the performance bottleneck anymore, and I'm curious if we think this sort of optimization would show real gains, performance-wise.
(In reply to Mark Michelson from comment #3) > I'm going to echo Dan's question from last year and ask if this is still > relevant. I suppose that the optimization potential may still exist, but the > bigger question is whether it's worth pursuing. We're in a different > position than we were 2 years ago with regards to OVN performance. These > days, ovn-controller is typically not the performance bottleneck anymore, > and I'm curious if we think this sort of optimization would show real gains, > performance-wise. Not sure whether this is a good argument as it's quite subjective but I think the code will also get significantly more complex than it already is.
(In reply to Mark Michelson from comment #3) > I'm going to echo Dan's question from last year and ask if this is still > relevant. I suppose that the optimization potential may still exist, but the > bigger question is whether it's worth pursuing. We're in a different > position than we were 2 years ago with regards to OVN performance. These > days, ovn-controller is typically not the performance bottleneck anymore, > and I'm curious if we think this sort of optimization would show real gains, > performance-wise. I think, at this stage this is more of a tech-debt task. Even though the code may become a bit more complex from one side, it should be much better isolated providing more flexibility to developers on how to use it. So, I'm not sure if this BZ should stay open or how much benefit it may provide if actually implemented. But that's a common thing with this kind of tech-debt tasks.
This issue is being closed as an automatic process due to the issue's age. If you wish to re-open this issue, please do so in Jira (https://issues.redhat.com) in the 'FDP' project. Please be sure to set the component to the latest OVN version where this issue is known to occur. If this is a feature request or improvement, please set the component to 'OVN'.