[PATCH v3] test/service: fix spurious failures by extending timeout

Van Haaren, Harry harry.van.haaren at intel.com
Mon Feb 27 09:41:18 CET 2023


> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: Thursday, February 23, 2023 8:11 PM
> To: Van Haaren, Harry <harry.van.haaren at intel.com>; dev at dpdk.org
> Cc: David Marchand <david.marchand at redhat.com>; 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>; Morten Brørup
> <mb at smartsharesystems.com>; Tyler Retzlaff <roretzla at linux.microsoft.com>;
> Aaron Conole <aconole at redhat.com>; Richardson, Bruce
> <bruce.richardson at intel.com>
> Subject: Re: [PATCH v3] test/service: fix spurious failures by extending timeout
> 
> 03/02/2023 16:12, Bruce Richardson:
> > On Fri, Feb 03, 2023 at 03:03:38PM +0000, Van Haaren, Harry wrote:
> > > From: Van Haaren, Harry
> > >
> > > <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?
> 
> Harry, you didn't reply to this question please.

Same answer as similar topic in the other thread:

> > I'm not aware of a way to make *a specific other pthread* wakeup.  We could sacrifice
> > the current lcore that's waiting for the service-lcore, with a sched_yield() as you suggest.
> > It would potentially "churn" the scheduler enough to give the service core some CPU?
> > It's a guess/gamble in the end, kind of like the timeouts we have today..

Patch sent as requested in other email.


More information about the dev mailing list