etzlaff ;
> Aaron Conole ; Richardson, Bruce
>
> Subject: Re: [PATCH v3] test/service: fix spurious failures by extending
> timeout
> > > We are talking about seconds.
> > > There are setups where scheduling a thread is taking seconds?
> >
> > Apparentl
up
> ; Tyler Retzlaff ;
> Aaron Conole ; Richardson, Bruce
>
> 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 +, Van Haaren, Harry wrote:
> > >
03/02/2023 17:09, Van Haaren, Harry:
> From: Thomas Monjalon
> > 03/02/2023 16:03, Van Haaren, Harry:
> > > From: Van Haaren, Harry
> > > > > 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
03/02/2023 16:12, Bruce Richardson:
> On Fri, Feb 03, 2023 at 03:03:38PM +, Van Haaren, Harry wrote:
> > From: Van Haaren, Harry
> >
> >
> >
> > > > 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
r Retzlaff ;
> Aaron Conole
> Subject: Re: [PATCH v3] test/service: fix spurious failures by extending
> timeout
>
> 03/02/2023 16:03, Van Haaren, Harry:
> > From: Van Haaren, Harry
> > > > The timeout approach just does not have its place in a functional test.
03/02/2023 16:03, Van Haaren, Harry:
> From: Van Haaren, Harry
> > > 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?
>
t; > honnappa.nagaraha...@arm.com; mattias.ronnblom
> > ; tho...@monjalon.net; Morten Brørup
> > ; Tyler Retzlaff ;
> > Aaron Conole
> > Subject: RE: [PATCH v3] test/service: fix spurious failures by extending
> > timeout
>
>
>
> >
> > > The tim
etzlaff ;
> Aaron Conole
> Subject: RE: [PATCH v3] test/service: fix spurious failures by extending
> timeout
>
> > 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
Tyler Retzlaff ;
> Aaron Conole
> Subject: Re: [PATCH v3] test/service: fix spurious failures by extending
> timeout
>
> Hello Harry,
Hi David,
> On Thu, Oct 6, 2022 at 9:33 PM David Marchand
> wrote:
> >
> > On Thu, Oct 6, 2022 at 3:27 PM Morten Brø
Hello Harry,
On Thu, Oct 6, 2022 at 9:33 PM David Marchand wrote:
>
> On Thu, Oct 6, 2022 at 3:27 PM Morten Brørup
> wrote:
> > > This commit extends the timeout for service_may_be_active()
> > > from 100ms to 1000ms. Local testing on a idle and loaded system
> > > (compiling DPDK with all core
On Thu, Oct 6, 2022 at 3:27 PM Morten Brørup wrote:
> > This commit extends the timeout for service_may_be_active()
> > from 100ms to 1000ms. Local testing on a idle and loaded system
> > (compiling DPDK with all cores) always completes after 1 ms.
> >
> > The wait time for a service-lcore to fini
On 2022-10-06 14:52, Harry van Haaren wrote:
> This commit extends the timeout for service_may_be_active()
> from 100ms to 1000ms. Local testing on a idle and loaded system
> (compiling DPDK with all cores) always completes after 1 ms.
>
> The wait time for a service-lcore to finish is also extend
> From: Harry van Haaren [mailto:harry.van.haa...@intel.com]
> Sent: Thursday, 6 October 2022 14.53
>
> This commit extends the timeout for service_may_be_active()
> from 100ms to 1000ms. Local testing on a idle and loaded system
> (compiling DPDK with all cores) always completes after 1 ms.
>
>
This commit extends the timeout for service_may_be_active()
from 100ms to 1000ms. Local testing on a idle and loaded system
(compiling DPDK with all cores) always completes after 1 ms.
The wait time for a service-lcore to finish is also extended
from 100ms to 1000ms.
The same timeout waiting code
14 matches
Mail list logo
