[PATCH v3] test/service: fix spurious failures by extending timeout
Bruce Richardson
bruce.richardson at intel.com
Fri Feb 3 16:12:44 CET 2023
On Fri, Feb 03, 2023 at 03:03:38PM +0000, Van Haaren, Harry wrote:
> > -----Original Message-----
> > From: Van Haaren, Harry
> > Sent: Tuesday, January 31, 2023 5:25 PM
> > To: David Marchand <david.marchand at redhat.com>
> > Cc: dev at dpdk.org; dpdklab at iol.unh.edu; ci at dpdk.org;
> > Honnappa.Nagarahalli at arm.com; mattias.ronnblom
> > <mattias.ronnblom at ericsson.com>; thomas at monjalon.net; Morten Brørup
> > <mb at smartsharesystems.com>; Tyler Retzlaff <roretzla at linux.microsoft.com>;
> > Aaron Conole <aconole at redhat.com>
> > Subject: RE: [PATCH v3] test/service: fix spurious failures by extending timeout
>
> <snip>
>
> > <snip>
> > > The timeout approach just does not have its place in a functional test.
> > > Either this test is rewritten, or it must go to the performance tests
> > > list so that we stop getting false positives.
> > > Can you work on this?
> >
> > I'll investigate various approaches on Thursday and reply here with suggested
> > next steps.
>
> I've identified 3 checks that fail in CI (from the above log outputs), all 3 cases
> Have different dlays: 100 ms delay, 200 ms delay and 1000ms.
> In the CI, the service-core just hasn't been scheduled (yet) and causes the "failure".
>
For me, the question is - why hasn't the service-core been scheduled? Can
we use sched-yield or some other mechanism to force a wakeup of it?
/Bruce
More information about the dev
mailing list