On 10/9/26 2:03 PM, Simon Horman wrote:
> On Thu, Oct 08, 2026 at 05:28:09PM +0200, Eelco Chaudron wrote:
>>
>>
>> On 8 Oct 2026, at 15:59, Simon Horman wrote:
>>
>>> On Thu, Oct 08, 2026 at 09:04:42AM +0200, Eelco Chaudron wrote:
>>>>
>>>>
>>>> On 7 Oct 2026, at 15:43, Simon Horman via dev wrote:
>>>>
>>>>> It appears that there is may be some delay in cleanup can results in
>>>>> this test failing because the port cannot be recreated.
>>>>>
>>>>> # make check-afxdp TESTSUITEFLAGS="2 -v"
>>>>> ...
>>>>> 2. system-afxdp.at:27: testing AF_XDP - ping between pmd and non-pmd
>>>>> ports
>>>>> ...
>>>>> 2026-10-07T10:38:10.997Z|00099|netdev_afxdp|ERR|xsk_socket__create
>>>>> failed
>>>>> (Device or resource busy) mode: generic, qid: 0
>>>>>
>>>>> My LLM tells me this is an issue with older kernels delaying cleanup.
>>>>> But it also calaimed this is addressed in the v5.15 kernel, while
>>>>> my kernel is much newer than that. So who knows.
>>>>>
>>>>> In any case I did I did not investigate beyond verifying that this patch
>>>>> addresses the failure I was seeing.
>>>>>
>>>>> Observed on RHEL 10.2 on aarch64.
>>>>> RHEL 10.2 ships with a heavily patched 6.12.0 kernel.
>>>>>
>>>>> Assisted-by: LLM
>>>>> Signed-off-by: Simon Horman <[email protected]>
>>>>
>>>> Hi Simon,
>>>>
>>>> Thanks for the patch and for looking into this. However, we are trying to
>>>> get rid of all the sleeps in the unit tests. Would it be possible to wait
>>>> for
>>>> the device to be removed? Maybe something like;
>>>>
>>>> OVS_WAIT_WHILE([ip link show ovs-p0]).
>>>
>>> Perhaps strangely it seems that condition is not met.
>>>
>>> This one is:
>>>
>>> OVS_WAIT_WHILE([ovs-vsctl list-ports br0 | grep -q ovs-p0])
>>>
>>> Curiously, straight away.
>>> But without that line the test fails in my environment.
>>
>> Interesting, is it retrying in the loop? I'm quite sure this is caused by the
>> delay, as 'ovs-vsctl list-ports br0' only reads the database, which was
>> already updated before the delete command returned.
>>
>> Not sure what else we could check for. We could retry the port addition, but
>> that doesn't feel right. Ilya, any ideas?
>
> I agree this is a bit odd.
> But, to clarify, the OVS_WAIT_WHILE() line I proposed above
> does solve the problem: the test now passes.
AFAIU, the socket destruction in the kernel is RCU-postponed and until
the memory pool for the queue is not released, the device returns EBUSY.
So, we have to wait for the kernel grace period, which is not something
we can do from userspace, IIUC. To be honest, this sounds like something
that should be fixed in the kernel, but it may also be hard to do.
One solution for this particular test would be to create the port with
the correct type from the beginning. Maybe something like this could
work:
diff --git a/tests/system-afxdp-macros.at b/tests/system-afxdp-macros.at
index 5ee2ceb1a..c6b8d473d 100644
--- a/tests/system-afxdp-macros.at
+++ b/tests/system-afxdp-macros.at
@@ -6,7 +6,9 @@ m4_define([ADD_VETH],
AT_CHECK([ip link set $1 netns $2])
AT_CHECK([ip link set dev ovs-$1 up])
AT_CHECK([ovs-vsctl add-port $3 ovs-$1 -- \
- set interface ovs-$1 external-ids:iface-id="$1" type="afxdp"])
+ set interface ovs-$1 external-ids:iface-id="$1" \
+ type="afxdp]m4_if(m4_index([$1], [nonpmd]),
+ [-1], [], [-nonpmd])["])
NS_CHECK_EXEC([$2], [ip addr add $4 dev $1 $7])
NS_CHECK_EXEC([$2], [ip link set dev $1 up])
if test -n "$5"; then
Not tested. The idea is to look at the port name and if it contains
"nonpmd", then add that to the type during the port creation.
Then we could rename the port in the test and drop the del/add sequence.
WDYT?
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
