Message ID | 20190329172241.11916-1-aconole@redhat.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B912E2C28; Fri, 29 Mar 2019 18:22:46 +0100 (CET) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 2E02C1B05 for <dev@dpdk.org>; Fri, 29 Mar 2019 18:22:44 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 41E053082E58 for <dev@dpdk.org>; Fri, 29 Mar 2019 17:22:44 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (ovpn-121-152.rdu2.redhat.com [10.10.121.152]) by smtp.corp.redhat.com (Postfix) with ESMTP id DC49060BFB for <dev@dpdk.org>; Fri, 29 Mar 2019 17:22:42 +0000 (UTC) From: Aaron Conole <aconole@redhat.com> To: dev@dpdk.org Date: Fri, 29 Mar 2019 13:22:38 -0400 Message-Id: <20190329172241.11916-1-aconole@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Fri, 29 Mar 2019 17:22:44 +0000 (UTC) Subject: [dpdk-dev] [RFC 0/3] ci: enable unit tests for non-aarch64 platforms X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
ci: enable unit tests for non-aarch64 platforms
|
|
Message
Aaron Conole
March 29, 2019, 5:22 p.m. UTC
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(-)
Comments
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 ? This is quite frustrating when testing "before" and "after" each patch.
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.
On Mon, Apr 1, 2019 at 9:28 PM Aaron Conole <aconole@redhat.com> wrote: > David Marchand <david.marchand@redhat.com> writes: > > 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. > Nop, I got this even before your first patch.
On Mon, Apr 01, 2019 at 09:29:51PM +0200, David Marchand wrote: > On Mon, Apr 1, 2019 at 9:28 PM Aaron Conole <aconole@redhat.com> wrote: > > > David Marchand <david.marchand@redhat.com> writes: > > > 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. > > > > Nop, I got this even before your first patch. > Is this meson related or related to the auto test binary in DPDK. I know traditionally I've found the test binary rather difficult to kill, but I'd like to be sure that the meson infrastructure itself isn't making it worse. /Bruce
On Tue, Apr 2, 2019 at 11:37 AM Bruce Richardson <bruce.richardson@intel.com> wrote: > On Mon, Apr 01, 2019 at 09:29:51PM +0200, David Marchand wrote: > > On Mon, Apr 1, 2019 at 9:28 PM Aaron Conole <aconole@redhat.com> wrote: > > > > > David Marchand <david.marchand@redhat.com> writes: > > > > 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. > > > > > > > Nop, I got this even before your first patch. > > > > Is this meson related or related to the auto test binary in DPDK. I know > traditionally I've found the test binary rather difficult to kill, but I'd > like to be sure that the meson infrastructure itself isn't making it worse. > Hard to tell, I would have to retest and investigate, unless Aaron went further than me.
David Marchand <david.marchand@redhat.com> writes: > On Tue, Apr 2, 2019 at 11:37 AM Bruce Richardson <bruce.richardson@intel.com> wrote: > > On Mon, Apr 01, 2019 at 09:29:51PM +0200, David Marchand wrote: > > On Mon, Apr 1, 2019 at 9:28 PM Aaron Conole <aconole@redhat.com> wrote: > > > > > David Marchand <david.marchand@redhat.com> writes: > > > > 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. > > > > > > > Nop, I got this even before your first patch. > > > > Is this meson related or related to the auto test binary in DPDK. I know > traditionally I've found the test binary rather difficult to kill, but I'd > like to be sure that the meson infrastructure itself isn't making it worse. > > Hard to tell, I would have to retest and investigate, unless Aaron went further than me. I did some investigation with this. At least I don't see any lingering process from meson, but it does take time for the tests to die when I hit CTRL-C, and I get a warning - I found this related bug: https://github.com/mesonbuild/meson/issues/2281 I guess it could be some kind of interplay between the way meson kills tests? Looking at the commit that eventually 'closes' the bug, they merely set a flag rather than pass a kill signal down, so I guess it's probably never going to be immediate.