[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <66e89af24d4a3_23d205294e4@willemb.c.googlers.com.notmuch>
Date: Mon, 16 Sep 2024 16:54:10 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Stanislav Fomichev <stfomichev@...il.com>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Matthieu Baerts <matttbe@...nel.org>,
netdev@...r.kernel.org,
davem@...emloft.net,
kuba@...nel.org,
edumazet@...gle.com,
pabeni@...hat.com,
ncardwell@...gle.com,
shuah@...nel.org,
linux-kselftest@...r.kernel.org,
Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net-next v2 0/3] selftests/net: packetdrill: netns and two
imports
Stanislav Fomichev wrote:
> On 09/12, Willem de Bruijn wrote:
> > Matthieu Baerts wrote:
> > > Hi Willem,
> > >
> > > On 12/09/2024 02:52, Willem de Bruijn wrote:
> > > > From: Willem de Bruijn <willemb@...gle.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@...nel.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&test=tcp-zerocopy-closed-pkt
> >
> > 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.com.notmuch/
>
> Not sure you've seen, but tcp_slow_start_slow-start-after-win-update.pkt
> also just popped up on the dashboard for dbg:
>
> # tcp_slow_start_slow-start-after-win-update.pkt:39: error handling packet: timing error: expected outbound packet in relative time range +0.600000~+0.620000
>
> https://netdev-3.bots.linux.dev/vmksft-packetdrill-dbg/results/774981/1-tcp-slow-start-slow-start-after-win-update-pkt/stdout
>
> Do we want to follow up with that '--tolerance_usecs=10000' you've
> mentioned above?
And more tests coming. Looks like it. I'll finish it up. Thanks for
the pointer.
Powered by blists - more mailing lists