On Fri, Mar 29, 2019 at 6:23 PM Aaron Conole <acon...@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
