All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Mastan Katragadda <mastanx.katragadda@intel.com>,
	igt-dev@lists.freedesktop.org,
	tejaskumarx.surendrakumar.upadhyay@intel.com
Cc: "Bloomfield, Jon" <jon.bloomfield@intel.com>
Subject: Re: [igt-dev] [i-g-t] tests/i915/exec_balancer: Added Skip Guc Submission
Date: Fri, 10 Dec 2021 10:02:41 +0000	[thread overview]
Message-ID: <36f819b9-8001-6087-8379-df57de5b1d73@linux.intel.com> (raw)
In-Reply-To: <20211209082053.1412439-1-mastanx.katragadda@intel.com>


Old commit message:

"""
This a known failure when running 
igt@gem_exec_balancer@bonded-(dual|pair|sync)
tests with GuC submission.The hang is expected with GuC submission since the
test was written to expect execlist scheduling hence added skip if Guc
submission enabled.
"""

New commit message:

On 09/12/2021 08:20, Mastan Katragadda wrote:
> This test makes assumptions about the backend scheduling algorithm that
> a real world UMD would never assume. This test is not testing a UMD-KMD
> contract, rather a specific backend.It is an invalid test case thus we
> are skipping.
> 
> Changes Since v1:
>               -Updated commit message

Well that hasn't been really improved at all an is still totally opaque. 
No mention whether it is all or some subtests, no mention of what 
assumptions, what exact usage of the ABI is discouraged, not much more 
than pure rewording.

No desire to split into passing and non passing tests and only skip 
latter group?

Or to add a twist, what about making the specific subtests which hang 
with GuC, expect to hang and therefore pass?

That would a) document the failing corner case of the ABI and more 
importantly b) keep exercising the i915 code paths which sit between the 
uAPI and the GuC firmware?

If that is not acceptable, and I do acknowledge to the cost to CI time, 
then architects should ack and in my mind the ack should mean one of the 
two things. Either:

  1) We know there is coverage for the same i915 code paths elsewhere in 
IGT. Or:

  2) We are willingly dropping coverage for these i915 code paths on GuC 
platforms with the risk that the code might unknowingly bit rot and 
cause more serious security issues down the line.

Regards,

Tvrtko

> 
> Cc: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: Mastan Katragadda <mastanx.katragadda@intel.com>
> ---
>   tests/i915/gem_exec_balancer.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
> index cc07a5a9..d58734ab 100644
> --- a/tests/i915/gem_exec_balancer.c
> +++ b/tests/i915/gem_exec_balancer.c
> @@ -3320,6 +3320,7 @@ igt_main
>   
>   	igt_subtest_group {
>   		igt_fixture {
> +			igt_require(!gem_using_guc_submission(i915));
>   			intel_allocator_multiprocess_start();
>   		}
>   
> 

  parent reply	other threads:[~2021-12-10 10:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-09  8:20 [igt-dev] [i-g-t] tests/i915/exec_balancer: Added Skip Guc Submission Mastan Katragadda
2021-12-09 22:24 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/i915/exec_balancer: Added Skip Guc Submission (rev3) Patchwork
2021-12-10  3:20 ` [igt-dev] [i-g-t] tests/i915/exec_balancer: Added Skip Guc Submission Matthew Brost
2021-12-10  8:26 ` [igt-dev] ✓ Fi.CI.IGT: success for tests/i915/exec_balancer: Added Skip Guc Submission (rev3) Patchwork
2021-12-10 10:02 ` Tvrtko Ursulin [this message]
2021-12-22  9:30   ` [igt-dev] [i-g-t] tests/i915/exec_balancer: Added Skip Guc Submission Tvrtko Ursulin
2021-12-22 21:02     ` John Harrison
2021-12-23 11:08       ` Tvrtko Ursulin
2021-12-23 11:16         ` Surendrakumar Upadhyay, TejaskumarX
  -- strict thread matches above, loose matches on Subject: below --
2021-11-26  1:57 Mastan Katragadda
2021-11-29 10:30 ` Tvrtko Ursulin
2021-11-29 10:58   ` Katragadda, MastanX
2021-11-29 11:15     ` Tvrtko Ursulin
2021-11-30 16:48       ` Matthew Brost
2021-12-01  9:46         ` Tvrtko Ursulin
2021-12-01 11:36           ` Radoslaw Szwichtenberg
2021-12-01 11:46             ` Daniel Vetter
2021-12-01 12:14               ` Tvrtko Ursulin
2021-12-01 23:57               ` Matthew Brost
2021-12-01 23:42           ` Matthew Brost
2021-12-02  9:19             ` Petri Latvala
2021-12-02  9:20             ` Tvrtko Ursulin
2021-12-03 19:36             ` Matthew Brost

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=36f819b9-8001-6087-8379-df57de5b1d73@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=jon.bloomfield@intel.com \
    --cc=mastanx.katragadda@intel.com \
    --cc=tejaskumarx.surendrakumar.upadhyay@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.