DPDK CI discussions
 help / color / mirror / Atom feed
* Re: [dpdk-ci] [dpdk-dev] [PATCH 00/14] Unit tests fixes for CI
       [not found] ` <81c5f665-97ac-c4d0-8281-8f195c63195e@redhat.com>
@ 2019-06-27 16:34   ` Thomas Monjalon
  2019-07-01 12:17     ` Aaron Conole
  0 siblings, 1 reply; 2+ messages in thread
From: Thomas Monjalon @ 2019-06-27 16:34 UTC (permalink / raw)
  To: msantana, David Marchand, aconole; +Cc: dev, ci

04/06/2019 17:49, Michael Santana Francisco:
> On 6/4/19 4:59 AM, David Marchand wrote:
> > - the "perf" tests are taking way too long for my taste,
> 
> We should still fix them. However I don't know if we should be running 
> the perf test for every job and every patch on travis. It takes too 
> long. The travis queue will be delayed too far behind for it to be of 
> any use.
> 
> OTOH we could have one job as part of the travis build dedicated to 
> running tests (or just perf test). It's still time consuming but better 
> than running the test on every travis job. For this to work we would 
> need to decreased the timeout for the perf tests as the timeout for it 
> and the travis are both 10 minutes

+Cc ci@dpdk.org

I don't think we should run the perf tests in basic CI like Travis.
We can run perf tests if the purpose is to compare the performance
with previous releases, as some other tests in the community lab.



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [dpdk-ci] [dpdk-dev] [PATCH 00/14] Unit tests fixes for CI
  2019-06-27 16:34   ` [dpdk-ci] [dpdk-dev] [PATCH 00/14] Unit tests fixes for CI Thomas Monjalon
@ 2019-07-01 12:17     ` Aaron Conole
  0 siblings, 0 replies; 2+ messages in thread
From: Aaron Conole @ 2019-07-01 12:17 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: msantana, David Marchand, dev, ci

Thomas Monjalon <thomas@monjalon.net> writes:

> 04/06/2019 17:49, Michael Santana Francisco:
>> On 6/4/19 4:59 AM, David Marchand wrote:
>> > - the "perf" tests are taking way too long for my taste,

+1 here.

>> 
>> We should still fix them. However I don't know if we should be running 
>> the perf test for every job and every patch on travis. It takes too 
>> long. The travis queue will be delayed too far behind for it to be of 
>> any use.
>> 
>> OTOH we could have one job as part of the travis build dedicated to 
>> running tests (or just perf test). It's still time consuming but better 
>> than running the test on every travis job. For this to work we would 
>> need to decreased the timeout for the perf tests as the timeout for it 
>> and the travis are both 10 minutes
>
> +Cc ci@dpdk.org
>
> I don't think we should run the perf tests in basic CI like Travis.
> We can run perf tests if the purpose is to compare the performance
> with previous releases, as some other tests in the community lab.

+1 - some of the perf tests aren't going to complete in any sort of
reasonable time.  While we could claim it's a separate problem, we
should also not enable something that will make the travis runs so much
longer.

I do like the idea of running tests in the travis build, and I think it
would make sense to have just a single job for it (or maybe one for
clang and one for gcc?  maybe even that is overkill).

I would rather not do performance tests during the travis run, though.
It doesn't really make sense.  Travis isn't any kind of an 'optimized'
environment, so I don't know what 'performance' should mean.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-07-01 12:17 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1559638792-8608-1-git-send-email-david.marchand@redhat.com>
     [not found] ` <81c5f665-97ac-c4d0-8281-8f195c63195e@redhat.com>
2019-06-27 16:34   ` [dpdk-ci] [dpdk-dev] [PATCH 00/14] Unit tests fixes for CI Thomas Monjalon
2019-07-01 12:17     ` Aaron Conole

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).