[PATCH v5 04/10] app/test: build using per-file dependency matrix

Bruce Richardson bruce.richardson at intel.com
Wed Aug 16 12:56:28 CEST 2023


On Tue, Aug 15, 2023 at 03:05:08PM -0400, Patrick Robb wrote:
>    Adam from our team just raised something important about this patch and
>    UNH CI which I missed during the RFC discussion.
>    Presently, eal_flags_file_prefix_autotest fails on arm tx2 systems (arm
>    people are aware of this, they think it might be a memory leak from
>    mlx5 driver), so at their request we are disabling this unit test (on
>    arm only) for them for the time being. This failure was discovered when
>    we were initially standing up arm unit testing on tx2 servers earlier
>    this year - previously there was no coverage for this. We do this
>    filtering by going through the /app/test/meson.build file and resetting
>    the eal_flags_file_prefix_autotest line to an empty string. This
>    process is broken by your patch series. Again, I'm sorry I didn't catch
>    this concern when discussing it during the RFC. This is why you are not
>    getting unit test results for arm64, we can't run unit tests given the
>    changes in this patch.

If this is a (semi)permanent issue, would it not be better to actually
patch in the disabling of this test into the test sources, i.e. if ARM64
have the test return TEST_SKIPPED?

>    Your refactor likely means that going forward, we will no longer be
>    able to tailor the fast test suite (or any suite) per vendor request.
>    That might actually be a good thing. In any case, if this is merged
>    now, it is going to put the tree in a state where our CI doesn't run
>    any unit testing on ARM. I don't know how close this patch series is to
>    possibly hitting mainline, but, if possible, can that be delayed,
>    pending us figuring out how we will respond to this situation?

There is at least one more issue I am aware of with this set - the failing
mempool tests - which needs to be fixed, so there will be at least one more
version.

If this is likely a common occurrance where we need to disable one
particular test for a particular platform, would it be worth designing such
a feature into the rework. For example, it should be fairly easy to have
the testname-extraction script read a blocklist from the environment, and
omit informing meson of those test cases. Would that work?

/Bruce


More information about the dev mailing list