From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id C470FA0679 for <public@inbox.dpdk.org>; Mon, 1 Apr 2019 21:16:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9D6553576; Mon, 1 Apr 2019 21:16:00 +0200 (CEST) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) by dpdk.org (Postfix) with ESMTP id 2FFD327D for <dev@dpdk.org>; Mon, 1 Apr 2019 21:15:59 +0200 (CEST) Received: by mail-vs1-f47.google.com with SMTP id e2so5520787vsc.13 for <dev@dpdk.org>; Mon, 01 Apr 2019 12:15:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6zvORB/Qg8DZOCk2/iPACozt2uUltdrp/SvdjXNLkac=; b=Od67wxWNcbl7URXTtifCcAiRvMP2pM/SYDuVZarHkrf3s7VEFS7mGcOvKRr9yilUYy GZXbomYklW58pfHjbVT/hfqukBXqCtWKzKSZgZEIh8rKbK0WqFeYpDWOCf0HrFgPD48c +ZhIpJ/Ssoov1Ulmk4M885xa2Ddjv/PCTE6w1RJixxdaB+2uT09RPhrSdfSrjMGSRoAa SWIH/t+qO+awqQjiZoEoKCez50iv/Nr/g5JrWzNwukB9jC7gXq7rE7wh2Xu/Kab0tZ20 iyxuA4Bphcx9NyuBSYtKgypQTltKvV8bZBmaVrnvAYumEgePBdd+sw748sedSkcaWclR lX4Q== X-Gm-Message-State: APjAAAVpwk08irOMujHr/d8rdlgPyjQdBQ/qfrEfRfts9N63HM0ssS1q 0+nI7ll1yuzuW0LtRKyVMa0rmmUfnYlLYftfbRr8yw== X-Google-Smtp-Source: APXvYqweNh2uG/qILfbEnbhQfeFh5UPmCdtqMn5Y6duaEzU+nSM+eLpO8JfDHVrGyZGDdgUqqytWKeg1EA5j9iLjWzU= X-Received: by 2002:a67:c812:: with SMTP id u18mr9928155vsk.87.1554146158580; Mon, 01 Apr 2019 12:15:58 -0700 (PDT) MIME-Version: 1.0 References: <20190329172241.11916-1-aconole@redhat.com> In-Reply-To: <20190329172241.11916-1-aconole@redhat.com> From: David Marchand <david.marchand@redhat.com> Date: Mon, 1 Apr 2019 21:15:47 +0200 Message-ID: <CAJFAV8wx152Em9C4iXwsf6K+D2HBVyeyreucCdKdAvxneVLQiA@mail.gmail.com> To: Aaron Conole <aconole@redhat.com> Cc: dev <dev@dpdk.org> Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 <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> Message-ID: <20190401191547.VMxufxlVVCyavUoIxe8UIHs7h39spW_s2bsrfFFbivc@z> 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