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.

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to