DPDK patches and discussions
 help / color / mirror / Atom feed
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.

  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).