diff options
author | Jakub Kicinski <kuba@kernel.org> | 2025-09-09 18:57:49 -0700 |
---|---|---|
committer | Jakub Kicinski <kuba@kernel.org> | 2025-09-09 18:57:49 -0700 |
commit | b90c7ca4f9185c0d31ebbe252a448c42a5983483 (patch) | |
tree | 59f9f5a525252023872ad36ef6851e7b9d9bb0fb /scripts/generate_rust_target.rs | |
parent | 4ea83b75735118eac40e6f76495d4a85373bd851 (diff) | |
parent | e2cda6343bfe459c3331db5afcd675ab333112dd (diff) |
Merge branch 'mptcp-make-add_addr-retransmission-timeout-adaptive'
Matthieu Baerts says:
====================
mptcp: make ADD_ADDR retransmission timeout adaptive
Currently, the MPTCP ADD_ADDR notifications are retransmitted after a
fixed timeout controlled by the net.mptcp.add_addr_timeout sysctl knob,
if the corresponding "echo" packets are not received before. This can be
too slow (or too quick), especially with a too cautious default value
set to 2 minutes.
- Patch 1: make ADD_ADDR retransmission timeout adaptive, using the
TCP's retransmission timeout. The corresponding sysctl knob is now
used as a maximum value.
- Patch 2: now that these ADD_ADDR retransmissions can happen faster,
all MPTCP Join subtests checking ADD_ADDR counters accept more
ADD_ADDR than expected (if any). This is aligned with the previous
behaviour, when the ADD_ADDR RTO was lowered down to 1 second.
- Patch 3: Some CIs have reported that some MPTCP Join signalling tests
were unstable. It seems that it is due to the time it can take in slow
environments to send a bunch of ADD_ADDR notifications and wait each
time for their echo reply. Use a longer transfer to avoid such errors.
v1: https://lore.kernel.org/d5397026-92eb-4a43-9534-954b43ab9305@kernel.org
====================
Link: https://patch.msgid.link/20250907-net-next-mptcp-add_addr-retrans-adapt-v1-0-824cc805772b@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'scripts/generate_rust_target.rs')
0 files changed, 0 insertions, 0 deletions