From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 43E5CA0547;
	Fri,  9 Apr 2021 17:33:55 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 060291410A9;
	Fri,  9 Apr 2021 17:33:54 +0200 (CEST)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com
 [64.147.123.19])
 by mails.dpdk.org (Postfix) with ESMTP id 2F5041410A8
 for <dev@dpdk.org>; Fri,  9 Apr 2021 17:33:52 +0200 (CEST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
 by mailout.west.internal (Postfix) with ESMTP id E50DBE46;
 Fri,  9 Apr 2021 11:33:50 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute2.internal (MEProxy); Fri, 09 Apr 2021 11:33:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=fm3; bh=
 aeTdOt5d3G5oG+LZ4MR74OIRAnzeImaRFSsDDTuK8tg=; b=u873p018zxnm92l6
 nYfrsGLwZOX+0rGUj4vP225IM4VPP6xX2+j/4rqgql4e8p7+4l/kR/M473ejQlB3
 f2oiNkhwb7HRiPR+QrOts2a2h3fAe6DCWcCdhN9g9jOD3IAs4WdU9y7G9xE4hoZ9
 lsJ4YkYoo2Sq73hjny99GvnGu36kADAVq9+ygQ0TKohVbkgwmBrBZw47/p2klkUM
 smT3H/i2RJ8FdiPZjM/nkHmKwVbbHa4gNJrWExU3C5Wk5USTbC1ui5ysziILwMj3
 ynVCvhRFxU8lYJ7wsKHYbKgJ2oYg6EWlZP7sQnFGW76nLmjazdODyIGmlpxySah7
 28g9SA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm2; bh=aeTdOt5d3G5oG+LZ4MR74OIRAnzeImaRFSsDDTuK8
 tg=; b=MT1/hsNU65Fg3s8CMT7x6GQHsnCQsHMUChT4um27lrnULHAXUVE/IBfF6
 Wjrz55KmYROm43L+noXQE3jy8CHNSgeFpOkw2gIaGk3i4szhNbav6tfst7FxPGbX
 hOpj9zj0FPjimOBmiqYTAuxWC2TmkD2Zogr10upTWt4U/kSaGVf3jX7BCzleq+Zc
 QmHVnzcTW+S+N6bz/w92xVbttq8ZGtgA3+2Ni9PwxAkEVX6Lbam/X6f4Rr5EvucU
 x3K4FYGkkwkwN2UHHAa/N2GrDoPr3JQnMUF7BAHSYryu/rn1Rl71YznUdeZn3cLh
 xba7v9Cl/ptxgPX8y5GT+kR8V/oaQ==
X-ME-Sender: <xms:3XNwYHvmA4xLmthUbm3NASIAVgOVQ0KYUPltZF1JiISdb-7y2lOftA>
 <xme:3XNwYIfAFYpASZ_CmejdO1vLvNTDxqiKC6Z8ojcEdji2Bk0zzC84whvzi5Wnj5kIf
 OnypKPRNFtQ80cN9w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudekuddgleduucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
 shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
 ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu
 ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf
 hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl
 ohhnrdhnvght
X-ME-Proxy: <xmx:3XNwYKybENyBAsXOZpccsvGQVWd0PC95JWSyY96bE70A6OHNVt5R3Q>
 <xmx:3XNwYGM8Yo7y7KQHSbGU13jcIcg17-F1S8xExTKPKGlhuOj0LutyUA>
 <xmx:3XNwYH9snKMtV1NGSqhqZXnNeX1smMFUrInyatoEXaXohYBxReHRVg>
 <xmx:3nNwYJLqsoo2IcSIEDHQ_Z97lm3dM53xCT0YU-maNYvcmn2MEts7Cg>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 2FE6724005A;
 Fri,  9 Apr 2021 11:33:49 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Aaron Conole <aconole@redhat.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>, dev@dpdk.org,
 David Marchand <david.marchand@redhat.com>, anatoly.burakov@intel.com
Date: Fri, 09 Apr 2021 17:33:47 +0200
Message-ID: <5237468.PbloVLfHjj@thomas>
In-Reply-To: <f7tblanjy4z.fsf@dhcp-25.97.bos.redhat.com>
References: <20210317144409.288346-1-aconole@redhat.com>
 <20210406145041.GC551@bricha3-MOBL.ger.corp.intel.com>
 <f7tblanjy4z.fsf@dhcp-25.97.bos.redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
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 <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>

09/04/2021 17:06, Aaron Conole:
> Bruce Richardson <bruce.richardson@intel.com> writes:
> 
> > On Tue, Apr 06, 2021 at 10:20:37AM -0400, Aaron Conole wrote:
> >> Bruce Richardson <bruce.richardson@intel.com> writes:
> >> 
> >> > On Tue, Apr 06, 2021 at 08:33:07AM -0400, Aaron Conole wrote:
> >> >> Thomas Monjalon <thomas@monjalon.net> 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.
> 
> I guess, I don't care too much which one is the one we choose.  My $.02
> opinion is that we already have most of the logic and whatnot done in
> the build system, so I'd prefer to do as small a change as possible
> (leaving that logic in the meson system).  Then again, maybe it makes
> more sense to just rip the bandaid off and move it all into the test
> framework.
> 
> WDYT?

I think the test application should adapt to its environment.
If no hugepage, then mark the tests requiring hugepages as skipped.
For the other tests, we could use --in-memory.