Matthieu Baerts wrote:
Hi Willem,
On 12/09/2024 02:52, Willem de Bruijn wrote:
From: Willem de Bruijn willemb@google.com
1/3: run in nets, as discussed, and add missing CONFIGs 2/3: import tcp/zerocopy 3/3: import tcp/slow_start
Thank you for the v2. This new version looks good to me:
Acked-by: Matthieu Baerts (NGI0) matttbe@kernel.org
I didn't pay too much attention to the new tests, because they look good, heavily tested I suppose, and I guess the goal is not to diverge from the original ones for the moment. Still, please note that the CI reported some timing issues with tcp_zerocopy_closed.pkt when using a debug kernel config, e.g.
tcp_zerocopy_closed.pkt:22: timing error: expected system call return at 0.100596 sec but happened at 0.109564 sec; tolerance 0.004000 sec
https://netdev.bots.linux.dev/contest.html?executor=vmksft-packetdrill-dbg&a...
Thanks Matthieu. I did not run the dbg variant often enough to observe that. Note to self to run more times before I submit.
It seems to fail 2/10 times on the dbg spinner. I don't have an explanation for the failure yet. The line itself has no expected delay
# script packet: 0.113203 S 0:0(0) <mss 1460,sackOK,TS val 0 ecr 0,nop,wscale 8> # actual packet: 0.107191 S 0:0(0) win 65535 <mss 1460,sackOK,TS val 0 ecr 0,nop,wscale 8>
+0.1 recvmsg(4, {msg_name(...)=..., msg_iov(1)=[{...,0}], msg_flags=MSG_ERRQUEUE, msg_control=[]}, MSG_ERRQUEUE) = -1 EAGAIN (Resource temporarily unavailable)
+0...0 connect(4, ..., ...) = 0
+0 > S 0:0(0) <mss 1460,sackOK,TS val 0 ecr 0,nop,wscale 8>
I guess the expectation includes the +0.1 delay before calling recvmsg, and that timer fired a bit early.
I previously shared a draft patch to adjust --tolerance_usecs in dbg runs. May have to send that after all.
https://lore.kernel.org/netdev/66da5b8b27259_27bb41294c@willemb.c.googlers.c...