From: Thomas Monjalon <thomas@monjalon.net>
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@arm.com
Subject: Re: [dpdk-dev] [PATCH] ci: increase unit test timeout
Date: Thu, 30 Jan 2020 12:03:05 +0100 [thread overview]
Message-ID: <36007098.10thIPus4b@xps> (raw)
In-Reply-To: <f7tlfprl2v7.fsf@dhcp-25.97.bos.redhat.com>
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).
next prev parent reply other threads:[~2020-01-30 11:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-28 16:28 [dpdk-dev] [PATCH] ci: increase unit test timeout Ferruh Yigit
2020-01-28 18:39 ` Michael Santana
2020-01-28 20:53 ` Aaron Conole
2020-01-30 11:03 ` Thomas Monjalon [this message]
2020-01-30 15:35 ` Honnappa Nagarahalli
2020-01-31 15:44 ` Honnappa Nagarahalli
2020-02-05 18:47 ` David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=36007098.10thIPus4b@xps \
--to=thomas@monjalon.net \
--cc=aconole@redhat.com \
--cc=agupta3@marvell.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=honnappa.nagarahalli@arm.com \
--cc=maicolgabriel@hotmail.com \
--cc=yipeng1.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.