On 3 Mar 2026, at 4:51, Mike Pattrick wrote:

> On Thu, Feb 26, 2026 at 8:35 AM Eelco Chaudron <[email protected]> wrote:
>
>>
>>
>> On 18 Feb 2026, at 22:37, Mike Pattrick via dev wrote:
>>
>>> Currently there is no rate limit on tunnel hardware address ARP/ND
>>> lookups. Furthermote, there is no indication for how frequently action
>>> translation composes these packets.
>>>
>>> This patch implements a limit of generating one packet per destination
>>> per second and adds a counter for each time a lookup happens.
>>>
>>> Fixes: a36de779d739 ("openvswitch: Userspace tunneling.")
>>> Reported-at: https://issues.redhat.com/browse/FDP-2986
>>> Signed-off-by: Mike Pattrick <[email protected]>
>>> ---
>>> v2:
>>>  - Allow the user to adjust the holdout timer
>>>  - Corrected atomic barrier types
>>>  - Display incomplete entries in tnl/neigh/show
>>> ---
>>
>> Thanks, Mike, for sending out v2 of the patch. I’ve looked at it and have
>> some comments below:
>>
>> //Eelco

[...]
>>>

>>> diff --git a/tests/tunnel-push-pop-ipv6.at b/tests/
>> tunnel-push-pop-ipv6.at
>>> index b11387345..2c885e1b5 100644
>>> --- a/tests/tunnel-push-pop-ipv6.at
>>> +++ b/tests/tunnel-push-pop-ipv6.at
>>> @@ -344,7 +344,20 @@ AT_CHECK([ovs-ofctl add-flow br0 action=normal])
>>>  dnl Check Neighbour discovery.
>>>  AT_CHECK([ovs-vsctl -- set Interface p0 options:pcap=p0.pcap])
>>>
>>> -AT_CHECK([ovs-appctl netdev-dummy/receive int-br
>> 'in_port(2),eth(src=aa:55:aa:55:00:00,dst=f8:bc:12:ff:ff:ff),eth_type(0x0800),ipv4(src=1.1.3.92,dst=1.1.3.88,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0)'])
>>> +dnl First trace should send only two ND lookups, for each destination IP
>>
>> Comments should end with a dot.
>>
>>> +AT_CHECK([ovs-appctl ofproto/trace ovs-dummy "in_port(int-br),]dnl
>>> +
>> [eth(src=aa:55:aa:55:00:00,dst=f8:bc:12:ff:ff:ff),eth_type(0x0800),]dnl
>>> +  [ipv4(src=1.1.3.92,dst=1.1.3.88,proto=1,tos=0,ttl=64,frag=no),]dnl
>>> +  [icmp(type=0,code=0)"], [0], [stdout])
>>> +AT_CHECK([grep -q "sending ND request" stdout], [0])
>>> +
>>> +dnl Second trace should not send any ND lookups
>>
>> Comments should end with a dot.
>>
>>> +AT_CHECK([ovs-appctl ofproto/trace ovs-dummy "in_port(int-br),]dnl
>>> +
>> [eth(src=aa:55:aa:55:00:00,dst=f8:bc:12:ff:ff:ff),eth_type(0x0800),]dnl
>>> +  [ipv4(src=1.1.3.92,dst=1.1.3.88,proto=1,tos=0,ttl=64,frag=no),]dnl
>>> +  [icmp(type=0,code=0)"], [0], [stdout])
>>> +AT_CHECK([grep -q "waiting on ND request" stdout], [0])
>>> +AT_CHECK([grep -qv "sending ND request" stdout], [0])
>>>
>>>  dnl Wait for the two Neighbor Solicitation packets to be sent.
>>>  dnl Sometimes the system can be slow (e.g. under valgrind)
>>> @@ -373,6 +386,7 @@ AT_CHECK([ovs-appctl tnl/neigh/set br0 2001:cafe::92
>> aa:bb:cc:00:00:01], [0], [O
>>>
>>>  AT_CHECK([ovs-appctl tnl/neigh/show | grep br0 | sort], [0], [dnl
>>>  2001:cafe::92                                 aa:bb:cc:00:00:01   br0
>>> +2001:cafe::93                                 00:00:00:00:00:00   br0
>> INCOMPLETE
>>>  ])
>>>
>>>  ovs-appctl time/warp 5000
>>> @@ -438,7 +452,8 @@ AT_CHECK([ovs-appctl netdev-dummy/receive p1
>> 'in_port(200),eth(src=f8:bc:12:44:3
>>>  ovs-appctl time/warp 1000
>>>  ovs-appctl time/warp 1000
>>>
>>> -AT_CHECK([ovs-appctl tnl/neigh/show | grep br | sort], [0], [dnl
>>> +dnl Previous receive causes a flood that results in a lookup of
>> 1.1.2.93.
>>> +AT_CHECK([ovs-appctl tnl/neigh/show | grep 92 | sort], [0], [dnl
>>
>> Wondering why we need this change? Is there more going on now?
>>
>
> Some of the flows in this test result in a flood which also triggers an arp
> lookup resulting in an incomplete entry. However, that incomplete entry
> isn't what the test is checking for, so I thought we should narrow what
> we're grepping for in this case.

Makes sense, however the 92, looks rather random, I feel like we should either 
grep for the full IP, or probably more clean ignore the INCOMPLETE entries, 
something like below, but it might require some line wrapping:

AT_CHECK([ovs-appctl tnl/neigh/show | grep br0 | grep -v INCOMPLETE | sort],
         [0], [dnl

[...]

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to