From: Aaron Conole <email@example.com> To: Thomas Monjalon <firstname.lastname@example.org> Cc: email@example.com, David Marchand <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: [dpdk-ci] [dpdk-dev] [PATCH 00/14] Unit tests fixes for CI Date: Mon, 01 Jul 2019 08:17:45 -0400 Message-ID: <email@example.com> (raw) In-Reply-To: <2134880.WhL1dmy7PZ@xps> Thomas Monjalon <firstname.lastname@example.org> 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 email@example.com > > 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.
prev parent reply index Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <firstname.lastname@example.org> [not found] ` <email@example.com> 2019-06-27 16:34 ` Thomas Monjalon 2019-07-01 12:17 ` Aaron Conole [this message]
Reply instructions: You may reply publically 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
DPDK CI discussions Archives are clonable: git clone --mirror http://inbox.dpdk.org/ci/0 ci/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ci ci/ http://inbox.dpdk.org/ci \ email@example.com public-inbox-index ci Newsgroup available over NNTP: nntp://inbox.dpdk.org/inbox.dpdk.ci AGPL code for this site: git clone https://public-inbox.org/ public-inbox