ci: increase unit test timeout

  Timeout multiplier was 3, which gives 30 seconds for unit test but still
some unit test was timing out time to time and travis reporting false
positive failures.

Increasing the multiplier to 10, which makes timeout duration
100seconds.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
 .ci/linux-build.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

I have been out of the loop for a while, so I do not know how many false 
positives there are. Looking at 
https://travis-ci.com/ovsrobot/dpdk/builds up to two weeks back it seems 
that hash_readwrite_lf_autotest is the only culprit. It looks like it 
lives in the neighborhood of 20-30s seconds so increasing the time out 
for this test seems appropriate as sometimes it halts at exactly 30s 
because of the time out.

Acked-by: Michael Santana <maicolgabriel@hotmail.com>

On 1/28/2020 11:28 AM, Ferruh Yigit wrote:
> Timeout multiplier was 3, which gives 30 seconds for unit test but still
> some unit test was timing out time to time and travis reporting false
> positive failures.
>
> Increasing the multiplier to 10, which makes timeout duration
> 100seconds.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
>   .ci/linux-build.sh | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
> index ccc3a7ccd..be3dc4940 100755
> --- a/.ci/linux-build.sh
> +++ b/.ci/linux-build.sh
> @@ -37,5 +37,5 @@ if [ "$AARCH64" != "1" ]; then
>   fi
>   
>   if [ "$RUN_TESTS" = "1" ]; then
> -    sudo meson test -C build --suite fast-tests -t 3
> +    sudo meson test -C build --suite fast-tests -t 10
>   fi
  

Ferruh Yigit <ferruh.yigit@intel.com> writes:

> Timeout multiplier was 3, which gives 30 seconds for unit test but still
> some unit test was timing out time to time and travis reporting false
> positive failures.
>
> Increasing the multiplier to 10, which makes timeout duration
> 100seconds.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---

It's okay to me.  I thought there was an effort to split out performance
part of this test from the functional part, but that seems to not have
gone anywhere.

Acked-by: Aaron Conole <aconole@redhat.com>


>  .ci/linux-build.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
> index ccc3a7ccd..be3dc4940 100755
> --- a/.ci/linux-build.sh
> +++ b/.ci/linux-build.sh
> @@ -37,5 +37,5 @@ if [ "$AARCH64" != "1" ]; then
>  fi
>  
>  if [ "$RUN_TESTS" = "1" ]; then
> -    sudo meson test -C build --suite fast-tests -t 3
> +    sudo meson test -C build --suite fast-tests -t 10
>  fi
  

28/01/2020 21:53, Aaron Conole:
> Ferruh Yigit <ferruh.yigit@intel.com> writes:
> 
> > Timeout multiplier was 3, which gives 30 seconds for unit test but still
> > some unit test was timing out time to time and travis reporting false
> > positive failures.
> >
> > Increasing the multiplier to 10, which makes timeout duration
> > 100seconds.
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > ---
> 
> It's okay to me.  I thought there was an effort to split out performance
> part of this test from the functional part, but that seems to not have
> gone anywhere.
> 
> Acked-by: Aaron Conole <aconole@redhat.com>

NACK
The fix should be to split perf tests out of fast-tests.

The following patch is splitting hash_readwrite_autotest:
	https://patchwork.dpdk.org/patch/58726/
But we are still waiting for a patch splitting hash_readwrite_lf_autotest.
Please consider working on unit tests as a HIGH PRIORITY (using uppercase ;).
We should not have to wait so long to see performance tests removed
from fast unit tests (while keeping the functional coverage).
  

> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, January 30, 2020 5:03 AM
> To: Ferruh Yigit <ferruh.yigit@intel.com>; Aaron Conole
> <aconole@redhat.com>; Amit Gupta <agupta3@marvell.com>
> Cc: dev@dpdk.org; Michael Santana <maicolgabriel@hotmail.com>;
> dev@dpdk.org; Aaron Conole <aconole@redhat.com>;
> david.marchand@redhat.com; yipeng1.wang@intel.com; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Subject: Re: [dpdk-dev] [PATCH] ci: increase unit test timeout
> 
> 28/01/2020 21:53, Aaron Conole:
> > Ferruh Yigit <ferruh.yigit@intel.com> writes:
> >
> > > Timeout multiplier was 3, which gives 30 seconds for unit test but
> > > still some unit test was timing out time to time and travis
> > > reporting false positive failures.
> > >
> > > Increasing the multiplier to 10, which makes timeout duration
> > > 100seconds.
> > >
> > > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > > ---
> >
> > It's okay to me.  I thought there was an effort to split out
> > performance part of this test from the functional part, but that seems
> > to not have gone anywhere.
> >
> > Acked-by: Aaron Conole <aconole@redhat.com>
> 
> NACK
> The fix should be to split perf tests out of fast-tests.
> 
> The following patch is splitting hash_readwrite_autotest:
> 	https://patchwork.dpdk.org/patch/58726/
> But we are still waiting for a patch splitting hash_readwrite_lf_autotest.
> Please consider working on unit tests as a HIGH PRIORITY (using uppercase ;).
> We should not have to wait so long to see performance tests removed from
> fast unit tests (while keeping the functional coverage).
Apologies, it slipped from my radar. Will send out a patch soon.

> 
>
  

> > Subject: Re: [dpdk-dev] [PATCH] ci: increase unit test timeout
> >
> > 28/01/2020 21:53, Aaron Conole:
> > > Ferruh Yigit <ferruh.yigit@intel.com> writes:
> > >
> > > > Timeout multiplier was 3, which gives 30 seconds for unit test but
> > > > still some unit test was timing out time to time and travis
> > > > reporting false positive failures.
> > > >
> > > > Increasing the multiplier to 10, which makes timeout duration
> > > > 100seconds.
> > > >
> > > > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > > > ---
> > >
> > > It's okay to me.  I thought there was an effort to split out
> > > performance part of this test from the functional part, but that
> > > seems to not have gone anywhere.
> > >
> > > Acked-by: Aaron Conole <aconole@redhat.com>
> >
> > NACK
> > The fix should be to split perf tests out of fast-tests.
> >
> > The following patch is splitting hash_readwrite_autotest:
> > https://patchwork.dpdk.org/patch/58726/
Thomas/David, is it possible to merge this patch? It is acked already. It would be good to have these changes for LF functional tests.

> > But we are still waiting for a patch splitting hash_readwrite_lf_autotest.
> > Please consider working on unit tests as a HIGH PRIORITY (using uppercase ;).
> > We should not have to wait so long to see performance tests removed
> > from fast unit tests (while keeping the functional coverage).
> Apologies, it slipped from my radar. Will send out a patch soon.
> 
> >
> >
>
  

On Thu, Jan 30, 2020 at 12:03 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 28/01/2020 21:53, Aaron Conole:
> > Ferruh Yigit <ferruh.yigit@intel.com> writes:
> >
> > > Timeout multiplier was 3, which gives 30 seconds for unit test but still
> > > some unit test was timing out time to time and travis reporting false
> > > positive failures.
> > >
> > > Increasing the multiplier to 10, which makes timeout duration
> > > 100seconds.
> > >
> > > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > > ---
> >
> > It's okay to me.  I thought there was an effort to split out performance
> > part of this test from the functional part, but that seems to not have
> > gone anywhere.
> >
> > Acked-by: Aaron Conole <aconole@redhat.com>
>
> NACK
> The fix should be to split perf tests out of fast-tests.
>
> The following patch is splitting hash_readwrite_autotest:
>         https://patchwork.dpdk.org/patch/58726/
> But we are still waiting for a patch splitting hash_readwrite_lf_autotest.
> Please consider working on unit tests as a HIGH PRIORITY (using uppercase ;).
> We should not have to wait so long to see performance tests removed
> from fast unit tests (while keeping the functional coverage).

Just applied series
https://patchwork.dpdk.org/project/dpdk/list/?series=8401&state=*.
So marking this patch as rejected.

Thanks.