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.march...@redhat.com> > > Cc: dev@dpdk.org; dpdk...@iol.unh.edu; c...@dpdk.org; > > honnappa.nagaraha...@arm.com; mattias.ronnblom > > <mattias.ronnb...@ericsson.com>; tho...@monjalon.net; Morten Brørup > > <m...@smartsharesystems.com>; Tyler Retzlaff <roret...@linux.microsoft.com>; > > Aaron Conole <acon...@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
