Hi Jakub,
On 10/06/2025 02:00, Jakub Kicinski wrote:
Most of the packetdrill tests have not flaked once last week. Add the few which did to the XFAIL list.
Thank you for monitoring these tests!
Signed-off-by: Jakub Kicinski kuba@kernel.org
CC: shuah@kernel.org CC: willemb@google.com CC: matttbe@kernel.org CC: linux-kselftest@vger.kernel.org
Every time I sit down to add more I plan to just XFAIL all of packetdrill on slow machines, but then I convince myself otherwise. One last time?
:)
Did some of these packetdrill tests fail only when using a debug kernel? But yes, I guess we can always say: "maybe one day that will pay off" :)
As long as it is manageable!
tools/testing/selftests/net/packetdrill/ksft_runner.sh | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/net/packetdrill/ksft_runner.sh b/tools/testing/selftests/net/packetdrill/ksft_runner.sh index ef8b25a606d8..c5b01e1bd4c7 100755 --- a/tools/testing/selftests/net/packetdrill/ksft_runner.sh +++ b/tools/testing/selftests/net/packetdrill/ksft_runner.sh @@ -39,11 +39,15 @@ if [[ -n "${KSFT_MACHINE_SLOW}" ]]; then # xfail tests that are known flaky with dbg config, not fixable. # still run them for coverage (and expect 100% pass without dbg). declare -ar xfail_list=(
"tcp_blocking_blocking-connect.pkt""tcp_blocking_blocking-read.pkt"
Please note that these two tests have "--tolerance_usecs=10000" in their script. This is overridden by the command line option added above when KSFT_MACHINE_SLOW is defined: "--tolerance_usecs=14000". But maybe for these two tests, the tolerance should be even higher than 14000 when using a debug kernel?
But maybe still better to add them to the XFAIL list and keep the code as it is.
Acked-by: Matthieu Baerts (NGI0) matttbe@kernel.org
"tcp_eor_no-coalesce-retrans.pkt" "tcp_fast_recovery_prr-ss.*.pkt"
"tcp_sack_sack-route-refresh-ip-tos.pkt""tcp_zerocopy_cl.*.pkt"
Cheers, Matt