From: John Harrison <john.c.harrison@intel.com>
To: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Kamil Konieczny <kamil.konieczny@linux.intel.com>,
<IGT-Dev@lists.freedesktop.org>,
Katarzyna Piecielska <katarzyna.piecielska@intel.com>
Subject: Re: [RFC i-g-t] kunit: Remove hard-coded test list from xe_live_ktest
Date: Mon, 16 Sep 2024 15:10:42 -0700 [thread overview]
Message-ID: <7968ee02-8cbd-4e66-8490-0628fb47b4a5@intel.com> (raw)
In-Reply-To: <3240976.5fSG56mABF@jkrzyszt-mobl2.ger.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 5497 bytes --]
On 9/16/2024 01:17, Janusz Krzysztofik wrote:
> Hi John,
>
> On Saturday, 14 September 2024 02:20:32 GMT+2 John Harrison wrote:
>> On 8/29/2024 02:57, Janusz Krzysztofik wrote:
>>> Hi John,
>>>
>>> On Wednesday, 28 August 2024 20:04:06 GMT+2 John Harrison wrote:
>>>> On 8/26/2024 06:07, Janusz Krzysztofik wrote:
>>>>> Hi John, Kamil,
>>>>>
>>>>> On Monday, 26 August 2024 13:46:45 GMT+2 Kamil Konieczny wrote:
>>>>>> Hi John.C.Harrison,
>>>>>> On 2024-08-23 at 11:24:18 -0700,John.C.Harrison@Intel.com wrote:
>>>>>>> From: johnharr<johnharr@invalid-email.com>
>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>> Again invalid e-mail here.
>>>>>>
>>>>>>> The list of supported kunit tests is currently hard coded.
>>>>> That pattern originates from i915_selftest, where there are 3 stable
> subtests,
>>>>> "mock", "live" and "perf", each of them executing a (possibly long) list
> of
>>>>> dynamic sub-subtests actually provided by the module for each category.
> Also,
>>>>> IIRC there was a separate module for each Xe test suite before, each
> mapped to
>>>>> a separate IGT test, later merged into one module with multiple suites
> and one
>>>>> test with multiple corresponding subtests.
>>>> Not sure if you are just explaining the history of the test or making a
>>>> suggestion as to how it should evolve next?
>>> Both, I think. Maybe not the history, but origin of ideas standing behind
> the
>>> implementation, and how tests are expected to use it (and maybe evolve if
> now
>>> doing that in a different way).
>>>
>>>>>>> Which means
>>>>>>> that adding a new test to the kernel also requires patches to IGT as
>>>>>>> well.
>>>>>>>
>>>>>>> The list of available kunit tests is already exported by the kernel.
>>>>>>> So there is no need to bake a list into the IGT source code. So, add
>>>>>>> support for querying the test list dynamically.
>>>>>>>
>>>>>>> NB: Currently, the test list can only be queried by root but the IGT
>>>>>>> build system queries all tests at compile time. In theory this should
>>>>>>> not be a problem. However, the kunit helper code is all written to run
>>>>>>> inside a test and not inside the prep code, which means that when it
>>>>>>> fails to open the root only interfaces, it calls 'skip'. And skip is
>>>>>>> not allowed outside of running a test. Hence the build fails with:
>>>>>>> skipping is allowed only in fixtures, subtests or igt_simple_main
>>>>>> Looks like we should fix it, move out skips from kunit libs.
>>>>> I suggest you consider a different approach: for a module, call
> igt_kunit()
>>>>> only once, with NULL suite argument. As a result, you'll get results
> from one
>>>>> IGT subtest called "<module_name>" with a bunch of IGT dynamic sub-
> subtests
>>>>> called "<test_suite>-<test_case>", one for each test case provided by
> the
>>>>> module.
>>>> I'm not following. This is what my patch does, isn't it?
>>> No, your patch introduces a runtime determined list of subtests --
> something
>>> not existent in IGT.
>>>
>>> An IGT test may consist of one or more statically defined subtests with
> pre-
>>> defined names. The term dynamic subtest is usually used in two meanings.
> It
>>> may mean a subtest of type igt_subtest_with_dynamic, still with a pre-
> defined
>>> name, but with a runtime determined list of sub-subtests, sometimes called
>>> dynamic sub-subtests, but often also called just dynamic subtests. Names
> of
>>> dynamic sub-subtests are determined at runtime.
>>>
>>> My approach tries to address your need for a maintenance-free kunit IGT
> test
>>> source file in a different way. I'm following the IGT standard of
> statically
>>> defined list of subtests with pre-defined names: one subtest of type
>>> igt_subtest_with_dynamic, named after the kunit test module name which you
>>> have to enter into the test code anyway, and providing all test cases from
>>> all test suites contained in that module reported as dynamic sub-subtests
>>> named <test_suite>-<test_case>.
>> Can you please prototype how to do this? I can read your words but I
>> don't really get your meaning and I have no clue how to implement what
>> you are saying.
> The test code may look as simple as:
>
> igt_main
> {
> igt_kunit("xe_live_test", NULL, NULL);
> }
>
> Then, igt_kunit() will use xe_live_test module and should report results from
> all its KUnit test cases as results from a set of IGT dynamic sub-subtests
> "<test_suite>-<test_case>" under a single IGT subtest "xe_live".
>
> Janusz
>
Doing that solves the problem of not generating a test list at compile
time. But it creates the problem of not being able to generate a test
list at all:
0:28> sudo ./build/tests/xe_live_ktest --show-testlist
igt@xe_live_ktest@xe_live
0:29> sudo ./build/tests/xe_live_ktest --list-subtests
xe_live
0:30> sudo ./build/tests/xe_live_ktest --describe
SUB xe_live ../lib/igt_kmod.c:1475:
NO DOCUMENTATION!
And that last is clearly wrong because if I don't have a comment
description of xe_live then it gives a build time error.
It is possible to run a specific sub-test, but you have to know the name
already. E.g.:
0:25> sudo ./build/tests/xe_live_ktest --dynamic-subtest xe_bo-xe_bo_evict_kunit
IGT-Version: 1.28-g8df80ef3edc8 (x86_64) (Linux: 6.11.0-rc5-g2g x86_64)
Using IGT_SRANDOM=1726523447 for randomisation
Starting subtest: xe_live
Starting dynamic subtest: xe_bo-xe_bo_evict_kunit
...
That seems less than ideal.
John.
[-- Attachment #2: Type: text/html, Size: 12343 bytes --]
next prev parent reply other threads:[~2024-09-16 22:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-23 18:24 [RFC i-g-t] kunit: Remove hard-coded test list from xe_live_ktest John.C.Harrison
2024-08-23 21:56 ` ✗ Fi.CI.BUILD: failure for " Patchwork
2024-08-23 22:05 ` ✗ GitLab.Pipeline: warning " Patchwork
2024-08-26 11:46 ` [RFC i-g-t] " Kamil Konieczny
2024-08-26 13:07 ` Janusz Krzysztofik
2024-08-28 18:04 ` John Harrison
2024-08-29 9:57 ` Janusz Krzysztofik
2024-08-29 10:40 ` Janusz Krzysztofik
2024-08-29 10:45 ` Janusz Krzysztofik
2024-09-14 0:20 ` John Harrison
2024-09-16 8:17 ` Janusz Krzysztofik
2024-09-16 22:10 ` John Harrison [this message]
2024-09-17 9:14 ` Janusz Krzysztofik
2024-08-28 18:03 ` John Harrison
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7968ee02-8cbd-4e66-8490-0628fb47b4a5@intel.com \
--to=john.c.harrison@intel.com \
--cc=IGT-Dev@lists.freedesktop.org \
--cc=janusz.krzysztofik@linux.intel.com \
--cc=kamil.konieczny@linux.intel.com \
--cc=katarzyna.piecielska@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox