On Thu Aug 13, 2026 at 8:55 PM CEST, Ihor Solodrai wrote:
> On 2026-08-13 2:38 a.m., Alexis Lothoré (eBPF Foundation) wrote:
>> Some tests, like tc_tunnel or tc_edt, sporadically fail in CI with the
>> following logs:
>>
>> (network_helpers.c:309: errno: Operation now in progress) \
>> Failed to connect to server
>> send_and_test_data:FAIL:connect to server unexpected error: -115
>>
>> This is due to SO_RCVTIMEO and SO_SNDTIMEO being set on the client
>> socket (see settimeo() in client_socket()), allowing connect() to return
>> an error and to set errno to EINPROGRESS instead of ETIMEDOUT.
>> Increasing the timeout value for those tests is likely not a good
>> solution (and it has already been done by commit 2790db208b44
>> ("selftests/bpf: Improve tc_tunnel test reliability")): some tests
>> expect some data transfer to fail, and so the timeout value would
>> increase overall test execution duration again (not only the connection,
>> but any socket operation).
>>
>> Another solution is to allocate a timeout budget specific to the
>> connection: we can apply a larger timeout only for connections, and once
>> the connection is established, set back the timeout configured through
>> opts->timeout_ms; this would allow connection to succeed under heavy CI
>> load, while keeping timeout reasonable for the rest of the test traffic.
>>
>> Set a larger SO_SNDTIMEO/SO_RCVTIMEO for the connection step, and reset
>> it back to the timeout configured by the test once the connection has
>> succeeded.
>>
>> Fixes: 99126abec5e5 ("bpf: selftests: A few improvements to
>> network_helpers.c")
>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <[email protected]>
>> ---
>> Hello,
>> this is the v4 of the series aiming to reduce the flakyness of
>> tc_tunnel/tc_edt tests in CI. This revision takes a step back, based on
>> Ihor's tests, and drops the poll loop in favor of a bare, larger
>> timeout value applied only for the connection step. The main downside
>> of this new mechanism is a slight increase of the duration for tests
>> expecting a connection failure. In my testing setup (x86-based Qemu on
>> my work laptop), I observed a ~10s increase (on a ~5m18 base for the
>> whole test_progs set).
>
> Acked-by: Ihor Solodrai <[email protected]>
>
> I think it's better to fix those comment nits.
ACK, I'll send a new rev then.
Thanks,
Alexis
