From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id CBF0CA0547; Fri, 9 Apr 2021 17:41:05 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5BEC91410A9; Fri, 9 Apr 2021 17:41:05 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mails.dpdk.org (Postfix) with ESMTP id E5AD814108E for ; Fri, 9 Apr 2021 17:41:03 +0200 (CEST) IronPort-SDR: isCNMLNe7zzAZLifd9m0bkAXY5T6etfu/5IJiFbIu5Vbscg048kxM0K8m15Z5jQIt81qGqjoNp 68xHGXsPyWDA== X-IronPort-AV: E=McAfee;i="6000,8403,9949"; a="193901289" X-IronPort-AV: E=Sophos;i="5.82,209,1613462400"; d="scan'208";a="193901289" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Apr 2021 08:41:02 -0700 IronPort-SDR: OrHRtFuwMvA46lQnmkkaE2MVgn+b2w6DPw7y2wJ9aZe54ZTN5vzFBK3AuYWJOdTPHyzm+HuabK l7s6J8/uxNmw== X-IronPort-AV: E=Sophos;i="5.82,209,1613462400"; d="scan'208";a="520322363" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.3.224]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 09 Apr 2021 08:40:57 -0700 Date: Fri, 9 Apr 2021 16:40:52 +0100 From: Bruce Richardson To: Aaron Conole Cc: Thomas Monjalon , dev@dpdk.org, David Marchand , anatoly.burakov@intel.com Message-ID: <20210409154052.GB1396@bricha3-MOBL.ger.corp.intel.com> References: <20210317144409.288346-1-aconole@redhat.com> <2080877.JXBMkDg2Jp@thomas> <20210406125835.GB551@bricha3-MOBL.ger.corp.intel.com> <20210406145041.GC551@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH] test: make hugepage check more robust under Linux X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" On Fri, Apr 09, 2021 at 11:06:20AM -0400, Aaron Conole wrote: > Bruce Richardson writes: > > > On Tue, Apr 06, 2021 at 10:20:37AM -0400, Aaron Conole wrote: > >> Bruce Richardson writes: > >> > >> > On Tue, Apr 06, 2021 at 08:33:07AM -0400, Aaron Conole wrote: > >> >> Thomas Monjalon writes: > >> >> > >> >> > 17/03/2021 15:44, Aaron Conole: > >> >> >> The hugepage test really needs to check multiple things on Linux: > >> >> >> > >> >> >> 1. Are hugepages reserved in the system? > >> >> >> > >> >> >> 2. Is the hugepage mountpoint available so that we can allocate them? > >> >> >> > >> >> >> 3. Do we have permissions to write into the hugepage mountpoint? > >> >> >> > >> >> >> The existing hugepage check only verifies the first. On some setups, > >> >> >> a non-root user won't have access to the mountpoint for hugepages to > >> >> >> be allocated and that needs to be reflected in the test as well. Add > >> >> >> such checks for Linux OS to give a more check when running test suites. > >> >> > > >> >> > Requirements 2 & 3 are optional. > >> >> > You don't need a mount point if using the option --in-memory. > >> >> > >> >> That's true, but it seems to break a few of the unit tests without. > >> >> I'll clarify the commit message. > >> >> > >> >> Additionally, I thought it would be simple to just incorporate your > >> >> suggestions - but it seems that meson / ninja doesn't have cascading > >> >> dependencies the way 'make' does (or, I haven't figured out from the > >> >> syntax how to do that) - a 'run_command' gets resolved at configure > >> >> time and it doesn't seem that we can make a run_target depend on another > >> >> run_target since dependencies are on file outputs. Maybe we do some > >> >> kind of trickery here where we write a file that the build script reads? > >> >> > >> >> I am trying to figure out how best to accomplish this - suggestions > >> >> welcome. > >> >> > >> > Sorry that I'm late to this thread. Can you perhaps explain what you mean > >> > by cascading dependencies in this instance, or what you are trying to do > >> > exactly that is not supported? > >> > >> I want to conditionally invoke the test suite with the hugepage tests, > >> and support the case that the machine has hugepages enabled, but not > >> accessible. > >> > >> Right now, if a user runs: > >> > >> meson build && ninja -C build test > >> > >> with hugepages allocated as a non-root user, they will see 'FAIL' > >> messages. This isn't very friendly, since the user would be confused. > >> > >> Right now, hugepage detection is done only at configure time (the > >> 'meson' step), and then the target is always run. > >> > >> For now, I will continue modifying the below script, but that will be a > >> detection at configure time, still. So the case where the user runs > >> 'meson' when they have hugepages, but those hugepages go away and then > >> they run 'ninja -C build test' will still be FAIL instead of SKIP (maybe > >> we need a more descriptive error when FAIL due to hugepages happen?) > >> > > > > This seems to me like the test binary itself should be checking the > > presence of hugepages, and reporting skips if necessary. It's not just when > > run through ninja that this functionality would be useful. > > Either way, there needs to be a rework - if we do it in the test binary, > then the tests that require hugepages need to be worked so that they > correctly detect lack of hugepage support before starting. If we keep > that knowledge in the meson system, then we need to change the way we > call the test binary script to support a more robust detection. > For putting the detection in the app, it's should just be a one-time detection at init, right? There aren't differing hugepage requiresments per test? If not, then any tests requiring hugepages just need to check a global var and return skipped if not. /Bruce