From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id E8C7AA0679 for ; Mon, 1 Apr 2019 21:28:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EE29D3576; Mon, 1 Apr 2019 21:28:44 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id E28CA34F3 for ; Mon, 1 Apr 2019 21:28:43 +0200 (CEST) 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 29001C05B1CB for ; Mon, 1 Apr 2019 19:28:43 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8239160C5F; Mon, 1 Apr 2019 19:28:40 +0000 (UTC) From: Aaron Conole To: David Marchand Cc: dev References: <20190329172241.11916-1-aconole@redhat.com> Date: Mon, 01 Apr 2019 15:28:39 -0400 In-Reply-To: (David Marchand's message of "Mon, 1 Apr 2019 21:15:47 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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.32]); Mon, 01 Apr 2019 19:28:43 +0000 (UTC) Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190401192839.lKPsFc-b-G8Gp1iXY3yxxTL_kNXqo3X1eHXQL6uG4-M@z> David Marchand writes: > On Fri, Mar 29, 2019 at 6:23 PM Aaron Conole 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.