MPTCP Linux Development
 help / color / mirror / Atom feed
* [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout
@ 2025-11-12  9:45 Matthieu Baerts (NGI0)
  2025-11-12  9:45 ` [PATCH mptcp-net 1/2] selftests: mptcp: join: endpoints: " Matthieu Baerts (NGI0)
                   ` (3 more replies)
  0 siblings, 4 replies; 8+ messages in thread
From: Matthieu Baerts (NGI0) @ 2025-11-12  9:45 UTC (permalink / raw)
  To: MPTCP Upstream; +Cc: Matthieu Baerts (NGI0)

A previous attempt was helping, but not enough as the background
connections were still stopped after the timeout. That's what the MPTCP
CI recently reported with the "delete and re-add" subtest taking a bit
more than one minute in a debug environment.

To play it safe, and because increasing the timeout for the background
connections doesn't change anything to the end result (the transfer is
not checked in this case), all subtests with a background connection not
waiting for it to end now have a longer timeout.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
Matthieu Baerts (NGI0) (2):
      selftests: mptcp: join: endpoints: longer timeout
      selftests: mptcp: join: userspace: longer timeout

 tools/testing/selftests/net/mptcp/mptcp_join.sh | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)
---
base-commit: 83290f9ea1dc9994e0064956147443b2fc290dca
change-id: 20251112-slft-longer-timeout-5a48e854a933

Best regards,
-- 
Matthieu Baerts (NGI0) <matttbe@kernel.org>


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH mptcp-net 1/2] selftests: mptcp: join: endpoints: longer timeout
  2025-11-12  9:45 [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout Matthieu Baerts (NGI0)
@ 2025-11-12  9:45 ` Matthieu Baerts (NGI0)
  2025-11-12  9:45 ` [PATCH mptcp-net 2/2] selftests: mptcp: join: userspace: " Matthieu Baerts (NGI0)
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 8+ messages in thread
From: Matthieu Baerts (NGI0) @ 2025-11-12  9:45 UTC (permalink / raw)
  To: MPTCP Upstream; +Cc: Matthieu Baerts (NGI0)

In rare cases, when the test environment is very slow, some endpoints
tests can fail because some expected events have not been seen.

Because the tests are expecting a long on-going connection, and they are
not waiting for the end of the transfer, it is fine to have a longer
timeout, and even go over the default one. This connection will be
killed at the end, after the verifications: increasing the timeout
doesn't change anything, apart from avoiding it to end before the end of
the verifications.

To play it safe, all endpoints tests not waiting for the end of the
transfer are now having a longer timeout: 2 minutes.

The Fixes commit was making the connection longer, but still, the
default timeout would have stopped it after 1 minute, which might not be
enough in very slow environments.

Fixes: 6457595db987 ("selftests: mptcp: join: endpoints: longer transfer")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 tools/testing/selftests/net/mptcp/mptcp_join.sh | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index 41ce0eeed72c..b058f78ea0bd 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -4090,7 +4090,7 @@ endpoint_tests()
 		pm_nl_set_limits $ns1 2 2
 		pm_nl_set_limits $ns2 2 2
 		pm_nl_add_endpoint $ns1 10.0.2.1 flags signal
-		{ test_linkfail=128 speed=slow \
+		{ timeout_test=120 test_linkfail=128 speed=slow \
 			run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
 		local tests_pid=$!
 
@@ -4117,7 +4117,7 @@ endpoint_tests()
 		pm_nl_set_limits $ns2 0 3
 		pm_nl_add_endpoint $ns2 10.0.1.2 id 1 dev ns2eth1 flags subflow
 		pm_nl_add_endpoint $ns2 10.0.2.2 id 2 dev ns2eth2 flags subflow
-		{ test_linkfail=128 speed=5 \
+		{ timeout_test=120 test_linkfail=128 speed=5 \
 			run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
 		local tests_pid=$!
 
@@ -4195,7 +4195,7 @@ endpoint_tests()
 		# broadcast IP: no packet for this address will be received on ns1
 		pm_nl_add_endpoint $ns1 224.0.0.1 id 2 flags signal
 		pm_nl_add_endpoint $ns1 10.0.1.1 id 42 flags signal
-		{ test_linkfail=128 speed=5 \
+		{ timeout_test=120 test_linkfail=128 speed=5 \
 			run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
 		local tests_pid=$!
 
@@ -4275,7 +4275,7 @@ endpoint_tests()
 		# broadcast IP: no packet for this address will be received on ns1
 		pm_nl_add_endpoint $ns1 224.0.0.1 id 2 flags signal
 		pm_nl_add_endpoint $ns2 10.0.3.2 id 3 flags subflow
-		{ test_linkfail=128 speed=20 \
+		{ timeout_test=120 test_linkfail=128 speed=20 \
 			run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
 		local tests_pid=$!
 

-- 
2.51.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH mptcp-net 2/2] selftests: mptcp: join: userspace: longer timeout
  2025-11-12  9:45 [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout Matthieu Baerts (NGI0)
  2025-11-12  9:45 ` [PATCH mptcp-net 1/2] selftests: mptcp: join: endpoints: " Matthieu Baerts (NGI0)
@ 2025-11-12  9:45 ` Matthieu Baerts (NGI0)
  2025-11-12 11:13 ` [PATCH mptcp-net 0/2] selftests: mptcp: join: " MPTCP CI
  2025-11-17 11:08 ` Matthieu Baerts
  3 siblings, 0 replies; 8+ messages in thread
From: Matthieu Baerts (NGI0) @ 2025-11-12  9:45 UTC (permalink / raw)
  To: MPTCP Upstream; +Cc: Matthieu Baerts (NGI0)

In rare cases, when the test environment is very slow, some userspace
tests can fail because some expected events have not been seen.

Because the tests are expecting a long on-going connection, and they are
not waiting for the end of the transfer, it is fine to have a longer
timeout, and even go over the default one. This connection will be
killed at the end, after the verifications: increasing the timeout
doesn't change anything, apart from avoiding it to end before the end of
the verifications.

To play it safe, all userspace tests not waiting for the end of the
transfer are now having a longer timeout: 2 minutes.

The Fixes commit was making the connection longer, but still, the
default timeout would have stopped it after 1 minute, which might not be
enough in very slow environments.

Fixes: 290493078b96 ("selftests: mptcp: join: userspace: longer transfer")
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 tools/testing/selftests/net/mptcp/mptcp_join.sh | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index b058f78ea0bd..541c2676c79e 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -3953,7 +3953,7 @@ userspace_tests()
 	   continue_if mptcp_lib_has_file '/proc/sys/net/mptcp/pm_type'; then
 		set_userspace_pm $ns1
 		pm_nl_set_limits $ns2 2 2
-		{ test_linkfail=128 speed=5 \
+		{ timeout_test=120 test_linkfail=128 speed=5 \
 			run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
 		local tests_pid=$!
 		wait_mpj $ns1
@@ -3986,7 +3986,7 @@ userspace_tests()
 	   continue_if mptcp_lib_has_file '/proc/sys/net/mptcp/pm_type'; then
 		set_userspace_pm $ns2
 		pm_nl_set_limits $ns1 0 1
-		{ test_linkfail=128 speed=5 \
+		{ timeout_test=120 test_linkfail=128 speed=5 \
 			run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
 		local tests_pid=$!
 		wait_mpj $ns2
@@ -4014,7 +4014,7 @@ userspace_tests()
 	   continue_if mptcp_lib_has_file '/proc/sys/net/mptcp/pm_type'; then
 		set_userspace_pm $ns2
 		pm_nl_set_limits $ns1 0 1
-		{ test_linkfail=128 speed=5 \
+		{ timeout_test=120 test_linkfail=128 speed=5 \
 			run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
 		local tests_pid=$!
 		wait_mpj $ns2
@@ -4035,7 +4035,7 @@ userspace_tests()
 	   continue_if mptcp_lib_has_file '/proc/sys/net/mptcp/pm_type'; then
 		set_userspace_pm $ns2
 		pm_nl_set_limits $ns1 0 1
-		{ test_linkfail=128 speed=5 \
+		{ timeout_test=120 test_linkfail=128 speed=5 \
 			run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
 		local tests_pid=$!
 		wait_mpj $ns2
@@ -4059,7 +4059,7 @@ userspace_tests()
 	   continue_if mptcp_lib_has_file '/proc/sys/net/mptcp/pm_type'; then
 		set_userspace_pm $ns1
 		pm_nl_set_limits $ns2 1 1
-		{ test_linkfail=128 speed=5 \
+		{ timeout_test=120 test_linkfail=128 speed=5 \
 			run_tests $ns1 $ns2 10.0.1.1 & } 2>/dev/null
 		local tests_pid=$!
 		wait_mpj $ns1

-- 
2.51.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout
  2025-11-12  9:45 [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout Matthieu Baerts (NGI0)
  2025-11-12  9:45 ` [PATCH mptcp-net 1/2] selftests: mptcp: join: endpoints: " Matthieu Baerts (NGI0)
  2025-11-12  9:45 ` [PATCH mptcp-net 2/2] selftests: mptcp: join: userspace: " Matthieu Baerts (NGI0)
@ 2025-11-12 11:13 ` MPTCP CI
  2025-11-17 11:08 ` Matthieu Baerts
  3 siblings, 0 replies; 8+ messages in thread
From: MPTCP CI @ 2025-11-12 11:13 UTC (permalink / raw)
  To: Matthieu Baerts; +Cc: mptcp

Hi Matthieu,

Thank you for your modifications, that's great!

Our CI did some validations and here is its report:

- KVM Validation: normal (except selftest_mptcp_join): Success! ✅
- KVM Validation: normal (only selftest_mptcp_join): Success! ✅
- KVM Validation: debug (except selftest_mptcp_join): Unstable: 1 failed test(s): selftest_diag 🔴
- KVM Validation: debug (only selftest_mptcp_join): Success! ✅
- KVM Validation: btf-normal (only bpftest_all): Success! ✅
- KVM Validation: btf-debug (only bpftest_all): Success! ✅
- Task: https://github.com/multipath-tcp/mptcp_net-next/actions/runs/19293439106

Initiator: Patchew Applier
Commits: https://github.com/multipath-tcp/mptcp_net-next/commits/fcb8a7e51251
Patchwork: https://patchwork.kernel.org/project/mptcp/list/?series=1022413


If there are some issues, you can reproduce them using the same environment as
the one used by the CI thanks to a docker image, e.g.:

    $ cd [kernel source code]
    $ docker run -v "${PWD}:${PWD}:rw" -w "${PWD}" --privileged --rm -it \
        --pull always mptcp/mptcp-upstream-virtme-docker:latest \
        auto-normal

For more details:

    https://github.com/multipath-tcp/mptcp-upstream-virtme-docker


Please note that despite all the efforts that have been already done to have a
stable tests suite when executed on a public CI like here, it is possible some
reported issues are not due to your modifications. Still, do not hesitate to
help us improve that ;-)

Cheers,
MPTCP GH Action bot
Bot operated by Matthieu Baerts (NGI0 Core)

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout
  2025-11-12  9:45 [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout Matthieu Baerts (NGI0)
                   ` (2 preceding siblings ...)
  2025-11-12 11:13 ` [PATCH mptcp-net 0/2] selftests: mptcp: join: " MPTCP CI
@ 2025-11-17 11:08 ` Matthieu Baerts
  2025-11-17 11:26   ` Matthieu Baerts
  2025-11-18  8:43   ` Geliang Tang
  3 siblings, 2 replies; 8+ messages in thread
From: Matthieu Baerts @ 2025-11-17 11:08 UTC (permalink / raw)
  To: MPTCP Linux

Hello,

On 12/11/2025 10:45, Matthieu Baerts (NGI0) wrote:
> A previous attempt was helping, but not enough as the background
> connections were still stopped after the timeout. That's what the MPTCP
> CI recently reported with the "delete and re-add" subtest taking a bit
> more than one minute in a debug environment.
> 
> To play it safe, and because increasing the timeout for the background
> connections doesn't change anything to the end result (the transfer is
> not checked in this case), all subtests with a background connection not
> waiting for it to end now have a longer timeout.

I hope it is OK if I apply these patches now: they are simple, linked to
recent patches, and we still have quite a few patches in the queue.

I'm planning to send them with other patches we have in the queue for
net ideally today.

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout
  2025-11-17 11:08 ` Matthieu Baerts
@ 2025-11-17 11:26   ` Matthieu Baerts
  2025-11-18  8:43   ` Geliang Tang
  1 sibling, 0 replies; 8+ messages in thread
From: Matthieu Baerts @ 2025-11-17 11:26 UTC (permalink / raw)
  To: MPTCP Linux

On 17/11/2025 12:08, Matthieu Baerts wrote:
> Hello,
> 
> On 12/11/2025 10:45, Matthieu Baerts (NGI0) wrote:
>> A previous attempt was helping, but not enough as the background
>> connections were still stopped after the timeout. That's what the MPTCP
>> CI recently reported with the "delete and re-add" subtest taking a bit
>> more than one minute in a debug environment.
>>
>> To play it safe, and because increasing the timeout for the background
>> connections doesn't change anything to the end result (the transfer is
>> not checked in this case), all subtests with a background connection not
>> waiting for it to end now have a longer timeout.
> 
> I hope it is OK if I apply these patches now: they are simple, linked to
> recent patches, and we still have quite a few patches in the queue.

Done:

New patches for t/upstream-net and t/upstream:
- 16a4ac47cd40: selftests: mptcp: join: endpoints: longer timeout
- 5dd3ee3a0e67: selftests: mptcp: join: userspace: longer timeout
- Results: b6737ab5301a..7cd73169934a (export-net)
- Results: 622c76f2be66..f642d28cfc23 (export)

Tests are now in progress:

- export-net:
https://github.com/multipath-tcp/mptcp_net-next/commit/660070b99dec84a338e2efd835be9a68f63316a1/checks
- export:
https://github.com/multipath-tcp/mptcp_net-next/commit/89520dc46a1f4d65bffc7bac94b57b3ecf12cbe9/checks

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout
  2025-11-17 11:08 ` Matthieu Baerts
  2025-11-17 11:26   ` Matthieu Baerts
@ 2025-11-18  8:43   ` Geliang Tang
  2025-11-18 16:06     ` Matthieu Baerts
  1 sibling, 1 reply; 8+ messages in thread
From: Geliang Tang @ 2025-11-18  8:43 UTC (permalink / raw)
  To: Matthieu Baerts, MPTCP Linux

Hi Matt,

On Mon, 2025-11-17 at 12:08 +0100, Matthieu Baerts wrote:
> Hello,
> 
> On 12/11/2025 10:45, Matthieu Baerts (NGI0) wrote:
> > A previous attempt was helping, but not enough as the background
> > connections were still stopped after the timeout. That's what the
> > MPTCP
> > CI recently reported with the "delete and re-add" subtest taking a
> > bit
> > more than one minute in a debug environment.
> > 
> > To play it safe, and because increasing the timeout for the
> > background
> > connections doesn't change anything to the end result (the transfer
> > is
> > not checked in this case), all subtests with a background
> > connection not
> > waiting for it to end now have a longer timeout.
> 
> I hope it is OK if I apply these patches now: they are simple, linked
> to
> recent patches, and we still have quite a few patches in the queue.
> 
> I'm planning to send them with other patches we have in the queue for
> net ideally today.

Sorry for the delay. I just replied my RB tags to them for -net.

Thanks,
-Geliang

> 
> Cheers,
> Matt

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout
  2025-11-18  8:43   ` Geliang Tang
@ 2025-11-18 16:06     ` Matthieu Baerts
  0 siblings, 0 replies; 8+ messages in thread
From: Matthieu Baerts @ 2025-11-18 16:06 UTC (permalink / raw)
  To: Geliang Tang; +Cc: MPTCP Linux

Hi Geliang,

On 18/11/2025 09:43, Geliang Tang wrote:
> On Mon, 2025-11-17 at 12:08 +0100, Matthieu Baerts wrote:
>> On 12/11/2025 10:45, Matthieu Baerts (NGI0) wrote:
>>> A previous attempt was helping, but not enough as the background
>>> connections were still stopped after the timeout. That's what the
>>> MPTCP
>>> CI recently reported with the "delete and re-add" subtest taking a
>>> bit
>>> more than one minute in a debug environment.
>>>
>>> To play it safe, and because increasing the timeout for the
>>> background
>>> connections doesn't change anything to the end result (the transfer
>>> is
>>> not checked in this case), all subtests with a background
>>> connection not
>>> waiting for it to end now have a longer timeout.
>>
>> I hope it is OK if I apply these patches now: they are simple, linked
>> to
>> recent patches, and we still have quite a few patches in the queue.
>>
>> I'm planning to send them with other patches we have in the queue for
>> net ideally today.
> 
> Sorry for the delay. I just replied my RB tags to them for -net.

No problem, I'm sure that kind of simple patch in the selftests would
have been accepted without additional tags. Thank you for having sent them!

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2025-11-18 16:06 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-12  9:45 [PATCH mptcp-net 0/2] selftests: mptcp: join: longer timeout Matthieu Baerts (NGI0)
2025-11-12  9:45 ` [PATCH mptcp-net 1/2] selftests: mptcp: join: endpoints: " Matthieu Baerts (NGI0)
2025-11-12  9:45 ` [PATCH mptcp-net 2/2] selftests: mptcp: join: userspace: " Matthieu Baerts (NGI0)
2025-11-12 11:13 ` [PATCH mptcp-net 0/2] selftests: mptcp: join: " MPTCP CI
2025-11-17 11:08 ` Matthieu Baerts
2025-11-17 11:26   ` Matthieu Baerts
2025-11-18  8:43   ` Geliang Tang
2025-11-18 16:06     ` Matthieu Baerts

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox