From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <aconole@redhat.com> Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id DFBB12C36 for <dev@dpdk.org>; Tue, 2 Apr 2019 14:49:13 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0D33358E38; Tue, 2 Apr 2019 12:49:13 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 68A58627DE; Tue, 2 Apr 2019 12:49:10 +0000 (UTC) From: Aaron Conole <aconole@redhat.com> To: David Marchand <david.marchand@redhat.com> Cc: Bruce Richardson <bruce.richardson@intel.com>, dev <dev@dpdk.org> References: <20190329172241.11916-1-aconole@redhat.com> <CAJFAV8wx152Em9C4iXwsf6K+D2HBVyeyreucCdKdAvxneVLQiA@mail.gmail.com> <f7ty34t1q54.fsf@dhcp-25.97.bos.redhat.com> <CAJFAV8zGeMhqsXBERR21mgoLpzsWkraP+3cC-vjzLk8AO+PTUw@mail.gmail.com> <20190402093736.GC1470@bricha3-MOBL.ger.corp.intel.com> <CAJFAV8x-JHU3qDkxbenXG7nHFbVVs8eWGpkYAiMbEe_51HybgQ@mail.gmail.com> Date: Tue, 02 Apr 2019 08:49:09 -0400 In-Reply-To: <CAJFAV8x-JHU3qDkxbenXG7nHFbVVs8eWGpkYAiMbEe_51HybgQ@mail.gmail.com> (David Marchand's message of "Tue, 2 Apr 2019 12:09:26 +0200") Message-ID: <f7tsgv0mv22.fsf@dhcp-25.97.bos.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 02 Apr 2019 12:49:13 +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 <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> X-List-Received-Date: Tue, 02 Apr 2019 12:49:14 -0000 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. 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 A1EF0A0679 for <public@inbox.dpdk.org>; Tue, 2 Apr 2019 14:49:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F3C8E2E81; Tue, 2 Apr 2019 14:49:14 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id DFBB12C36 for <dev@dpdk.org>; Tue, 2 Apr 2019 14:49:13 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0D33358E38; Tue, 2 Apr 2019 12:49:13 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 68A58627DE; Tue, 2 Apr 2019 12:49:10 +0000 (UTC) From: Aaron Conole <aconole@redhat.com> To: David Marchand <david.marchand@redhat.com> Cc: Bruce Richardson <bruce.richardson@intel.com>, dev <dev@dpdk.org> References: <20190329172241.11916-1-aconole@redhat.com> <CAJFAV8wx152Em9C4iXwsf6K+D2HBVyeyreucCdKdAvxneVLQiA@mail.gmail.com> <f7ty34t1q54.fsf@dhcp-25.97.bos.redhat.com> <CAJFAV8zGeMhqsXBERR21mgoLpzsWkraP+3cC-vjzLk8AO+PTUw@mail.gmail.com> <20190402093736.GC1470@bricha3-MOBL.ger.corp.intel.com> <CAJFAV8x-JHU3qDkxbenXG7nHFbVVs8eWGpkYAiMbEe_51HybgQ@mail.gmail.com> Date: Tue, 02 Apr 2019 08:49:09 -0400 In-Reply-To: <CAJFAV8x-JHU3qDkxbenXG7nHFbVVs8eWGpkYAiMbEe_51HybgQ@mail.gmail.com> (David Marchand's message of "Tue, 2 Apr 2019 12:09:26 +0200") Message-ID: <f7tsgv0mv22.fsf@dhcp-25.97.bos.redhat.com> 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.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 02 Apr 2019 12:49:13 +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 <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: <20190402124909.mlEh1b3G7dIbsC2iVz5_mJ2lpYdSyvKJz2GPdcRxahk@z> 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.