Re: [PATCH bpf v4] selftests/bpf: allocate a larger timeout for connection

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