On 6/23/25 8:26 AM, Han Zhou wrote: [...]
>> >> In any case: >> >> Acked-by: Dumitru Ceara <dce...@redhat.com> >> > Hi Han, > Thanks Dumitru. Your suggestion of using revalidator/pause and resume is > really good. With this we don't have to do nc in a loop. I updated the test > case with this approach and just doing a single nc would reveal the hw > offload problem (I verified it using the new test case before the fix). > > So I merged it with the below small change: > > ------------------- > diff --git a/tests/system-ovn-kmod.at b/tests/system-ovn-kmod.at > index f47806db7d9e..48d7e86f4cfa 100644 > --- a/tests/system-ovn-kmod.at > +++ b/tests/system-ovn-kmod.at > @@ -1690,9 +1690,9 @@ dnl Wait for ovn-controller to catch up. > wait_for_ports_up > check ovn-nbctl --wait=hv sync > > -for i in $(seq 10); do > - NS_CHECK_EXEC([vm2], [nc -z 42.42.42.2 8080], 0, [ignore], [ignore]) > -done > +ovs-appctl revalidator/pause > +on_exit 'ovs-appctl revalidator/resume' > +NS_CHECK_EXEC([vm2], [nc -z 42.42.42.2 8080], 0, [ignore], [ignore]) > > dnl For each DP flow with ct action, make sure a CT entry exists as > established > dnl for the zone the ct action is taken. Otherwise it means HW offload is > @@ -1737,6 +1737,8 @@ ovs-appctl dpctl/dump-flows -m \ > check_flow_assured "$flow" > done > > +ovs-appctl revalidator/resume > + > OVS_APP_EXIT_AND_WAIT([ovn-controller]) > > as ovn-sb > ------------------- > > Now regarding backporting, I think we should backport to 24.09 and 24.03. > Any concerns? > I think that's the best thing to do indeed. One thing we need to take care of (downstream and in ovn-kubernetes) is to make sure we don't move to an OVN version that includes the revert but doesn't include the ovn-kubernetes SNAT port range change. But that shouldn't block the OVN backport, so it's fine from my perspective to backport your patch to 25.03, 24.09 and 24.03. Regards, Dumitru _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
