Jakub Kicinski wrote:
On Sun, 22 Dec 2024 22:46:26 -0500 Willem de Bruijn wrote:
Jakub Kicinski wrote:
On Thu, 19 Dec 2024 14:31:44 -0500 Willem de Bruijn wrote:
All three timestamping flakes are instances where the script expects the timestamp to be taken essentially instantaneously after the send call.
This is not the case, and the delay is outside even the 14K tolerance. I see occurrences of 20K. At some point we cannot keep increasing the tolerance, perhaps.
I pinned the other services away and gave the packetdrill tester its own cores. Let's see how much of a difference this makes. The net-next-2024-12-20--03-00 branch will be the first to have this.
Thanks. It does not seem to resolve the flakes.
At this point I think the best path is to run them in debug mode to get coverage, but ignore errors. With the below draft patch, error output is still logged. For instance:
# tcp_timestamping_partial.pkt:58: runtime error in recvmsg call: Bad timestamp 0 in scm_timestamping 0: expected=1734924748967958 (20000) actual=1734924748982069 (34111) start=1734924748947958 # ok 2 ipv6 # SKIP
Makes sense. Can we make this XFAIL instead of SKIP, tho? Not exactly accurate but we try to use SKIP for reporting env / setup problems like missing commands. We have FAIL_TO_XFAIL and xfail_on_slow() in the lib for netdev bash tests, already.
Sounds good. I'll add a ktap_test_xfail() to stay with that API. I see no clean way to make use of xfail_on_slow directly.
When net-next reopens, unless the noisy dash is annoying.