From: Aaron Conole <aconole@redhat.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC 0/3] ci: enable unit tests for non-aarch64 platforms
Date: Mon, 01 Apr 2019 15:28:39 -0400 [thread overview]
Message-ID: <f7ty34t1q54.fsf@dhcp-25.97.bos.redhat.com> (raw)
Message-ID: <20190401192839.lKPsFc-b-G8Gp1iXY3yxxTL_kNXqo3X1eHXQL6uG4-M@z> (raw)
In-Reply-To: <CAJFAV8wx152Em9C4iXwsf6K+D2HBVyeyreucCdKdAvxneVLQiA@mail.gmail.com> (David Marchand's message of "Mon, 1 Apr 2019 21:15:47 +0200")
David Marchand <david.marchand@redhat.com> writes:
> On Fri, Mar 29, 2019 at 6:23 PM Aaron Conole <aconole@redhat.com> wrote:
>
> This series is submitted as an RFC because a number of the unit tests are
> not successful in the travis environment. If all of them were passing,
> this would be submitted as PATCH instead. It could be accepted as-is but I
> would prefer to see all the tests passing first.
>
> The first patch fixes up the tests to auto-detect the number of cores on
> a machine. This helps on lower-end systems (such as i3 laptops or something)
> where someone wants to verify the functionality. The number of available
> cores on the running system will be picked based on the running system
> parameters.
>
> The second patch moves some tests out - these tests don't produce output or
> complete in any reasonable amount of time (10m+ for a single unit test is
> a little strange - they should be investigated to see if the run time can
> be reduced). I prefer to see these separated out since travis will completely
> bail if the test takes longer than 10m to produce output.
>
> The third actually enables the testing, and runs each test leg independently.
> This version populates the hugepages mapping. However, it might be useful
> to have the option of running without hugepages enabled (and I have a
> separate series that can do this). However, the --no-huge flag seems to cause
> most of the unit tests to break since they either spawn a new instance of
> the EAL without passing the hugepage flags, or check against the hugepage API
> and use that to determine whether memory can be allocated.
>
> Aaron Conole (3):
> test/meson: auto detect number of cores
> meson-tests: separate slower tests
> ci: enable tests on non-arm platforms
>
> .ci/linux-build.sh | 7 +++++++
> .ci/linux-setup.sh | 6 +++++-
> app/test/meson.build | 43 +++++++++++++++++++++++++++++++++----------
> 3 files changed, 45 insertions(+), 11 deletions(-)
>
> I tried using meson/ninja for the tests, something that bothered me is that I can't interrupt the tests.
> I had to kill manually, meson, ninja and I had some leftover dpdk-test processes (maybe due to some ^Z I
> hit...).
> Is this expected ?
Certainly not by me. I usually let everything complete, though (which
takes a looong time if I run the full suite).
> This is quite frustrating when testing "before" and "after" each patch.
Agreed. :-/
I'll have to try it out to see what's happening. Does it only happen
with this series? I'd be surprised, but possibly I introduced some error.
next prev parent reply other threads:[~2019-04-01 19:28 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-29 17:22 Aaron Conole
2019-03-29 17:22 ` Aaron Conole
2019-03-29 17:22 ` [dpdk-dev] [RFC 1/3] test/meson: auto detect number of cores Aaron Conole
2019-03-29 17:22 ` Aaron Conole
2019-04-01 13:48 ` David Marchand
2019-04-01 13:48 ` David Marchand
2019-04-01 14:07 ` Aaron Conole
2019-04-01 14:07 ` Aaron Conole
2019-04-01 16:23 ` Pattan, Reshma
2019-04-01 16:23 ` Pattan, Reshma
2019-04-01 17:48 ` Aaron Conole
2019-04-01 17:48 ` Aaron Conole
2019-04-01 19:39 ` Thomas Monjalon
2019-04-01 19:39 ` Thomas Monjalon
2019-04-01 19:58 ` Aaron Conole
2019-04-01 19:58 ` Aaron Conole
2019-03-29 17:22 ` [dpdk-dev] [RFC 2/3] meson-tests: separate slower tests Aaron Conole
2019-03-29 17:22 ` Aaron Conole
2019-03-29 17:22 ` [dpdk-dev] [RFC 3/3] ci: enable tests on non-arm platforms Aaron Conole
2019-03-29 17:22 ` Aaron Conole
2019-04-17 8:32 ` Jerin Jacob Kollanukkaran
2019-04-17 8:32 ` Jerin Jacob Kollanukkaran
2019-04-17 12:39 ` Aaron Conole
2019-04-17 12:39 ` Aaron Conole
2019-04-17 15:32 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-04-17 15:32 ` Jerin Jacob Kollanukkaran
2019-04-01 19:15 ` [dpdk-dev] [RFC 0/3] ci: enable unit tests for non-aarch64 platforms David Marchand
2019-04-01 19:15 ` David Marchand
2019-04-01 19:28 ` Aaron Conole [this message]
2019-04-01 19:28 ` Aaron Conole
2019-04-01 19:29 ` David Marchand
2019-04-01 19:29 ` David Marchand
2019-04-02 9:37 ` Bruce Richardson
2019-04-02 9:37 ` Bruce Richardson
2019-04-02 10:09 ` David Marchand
2019-04-02 10:09 ` David Marchand
2019-04-02 12:49 ` Aaron Conole
2019-04-02 12:49 ` Aaron Conole
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=f7ty34t1q54.fsf@dhcp-25.97.bos.redhat.com \
--to=aconole@redhat.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).