[dpdk-dev] [PATCH] test: make hugepage check more robust under Linux

[Bruce Richardson]

On Fri, Apr 09, 2021 at 11:06:20AM -0400, Aaron Conole wrote:
> Bruce Richardson <bruce.richardson at intel.com> writes:
> 
> > On Tue, Apr 06, 2021 at 10:20:37AM -0400, Aaron Conole wrote:
> >> Bruce Richardson <bruce.richardson at intel.com> writes:
> >> 
> >> > On Tue, Apr 06, 2021 at 08:33:07AM -0400, Aaron Conole wrote:
> >> >> Thomas Monjalon <thomas at 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.
> 
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