On 7/13/26 5:29 PM, Ilya Maximets wrote: > On 7/13/26 5:11 PM, David Marchand wrote: >> On Mon, 13 Jul 2026 at 14:32, Ilya Maximets <[email protected]> wrote: >>> >>> On 7/13/26 1:52 PM, David Marchand wrote: >>>> On Fri, 10 Jul 2026 at 09:09, David Marchand via dev >>>> <[email protected]> wrote: >>>>> >>>>> Instead of dropping we can switch to software segmentation before >>>>> encapsulating packets already encapsulated in a tunnel. >>>>> >>>>> Signed-off-by: David Marchand <[email protected]> >>>> >>>> Recheck-request: github-robot >>> >>> FWIW, while the test failure is sort of related to the set, the >>> issue is in the test. AFAIU, what happened is an icmp6 packet >>> entered OpenFlow pipeline before all the rules were installed >>> and hit a bunch of resubmits with the output to local port >>> without reaching the resubmit limit creating the datapath flow >>> with a ton of output actions to the same local port, resulting >>> in the large number of clones queued for output to the same >>> port, which was reflected in the output batch growing. >>> >>> The solution here would be to properly allow icmpv6 packets >>> to flow via normal action, setting correct priorities and using >>> a bundle to avoid partial pipeline execution. >>> >>> Something like this: >>> >>> diff --git a/tests/system-traffic.at b/tests/system-traffic.at >>> index 62567028e..6550f90d9 100644 >>> --- a/tests/system-traffic.at >>> +++ b/tests/system-traffic.at >>> @@ -2538,14 +2538,17 @@ ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24") >>> ADD_VETH(p1, at_ns1, br0, "10.1.1.2/24") >>> >>> dnl Exceed the max number of resubmits. >>> -(echo "dl_type=0x806, actions=normal" >>> +( >>> +echo "priority=100, arp, actions=normal" >>> +echo "priority=100, icmp6, actions=normal" >>> + >>> for i in $(seq 1 64); do >>> j=$(expr $i + 1) >>> - echo "in_port=$i, actions=resubmit:$j, resubmit:$j, local" >>> - done >>> - echo "in_port=65, actions=local" >>> + echo "priority=0, in_port=$i, actions=resubmit:$j, resubmit:$j, local" >>> +done >>> +echo "priority=0, in_port=65, actions=local" >>> ) > flows.txt >>> -AT_CHECK([ovs-ofctl add-flows br0 flows.txt]) >>> +AT_CHECK([ovs-ofctl add-flows --bundle br0 flows.txt]) >>> >>> dnl Generate some traffic. >>> NS_CHECK_EXEC([at_ns0], [ping -q -c 10 -i 0.1 -w 2 10.1.1.2], [1], >>> [ignore]) >>> -- >>> >>> I'll do some more testing and send this as a separate fix. >> >> I was quite skeptical about the value I saw in the test output files. >> Thanks for the explanation. >> >> >> This series may end up uncovering various test issues, but I think it >> is worth keeping the check in OVS_VSWITCHD_STOP. >> It forces us to have a good understanding of what is actually tested. > > I agree. In this particular case, for example, the test wasn't > well-designed. And we should fix this kind of stuff anyway if > we want our test suite to be reliable. > > For the set itself, the v2 looked good to me. I'll give it > another read and a quick performance run in my setup and plan > to apply if noting jumps out.
So, I found one issue in the patch 9 that we should probably fix before applying the set. And since some changes are needed, I also posted a few small nits here and there. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
