Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Harish Chegondi <harish.chegondi@intel.com>,
	Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>,
	 felix.j.degrood@intel.com, Jose Souza <jose.souza@intel.com>,
	matias.a.cabral@intel.com
Subject: Re: [PATCH v2 1/1] drm/xe/eustall: Add support for EU stall sampling
Date: Fri, 16 Aug 2024 15:37:55 -0700	[thread overview]
Message-ID: <878qww3xh8.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20240707224141.2865472-2-ashutosh.dixit@intel.com>

On Sun, 07 Jul 2024 15:41:41 -0700, Ashutosh Dixit wrote:

Hi Harish,

Some comments below on just the uapi first, towards finalizing the uapi
with the UMD's who consume this data. And also comparing the uapi with what
we did in OA.

>
> diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> index 19619d4952a8..343de700d10d 100644

/snip/

> +/**
> + * struct drm_xe_eu_stall_data_header - EU stall data header.
> + * Header with additional information that the driver adds
> + * before EU stall data of each subslice during read().

One question to resolve is if we really need this header and if UMD's are
actually using the information in this header. In OA we dropped the
header and are providing information in the header via different means (see
below).

Another option is to actually add a property for the header. So headers are
added only when user space requests headers.

> + */
> +struct drm_xe_eu_stall_data_header {
> +	/** @subslice: subslice number from which the following data
> +	 * has been captured.
> +	 */
> +	__u16 subslice;

Do UMD's use this subslice information? We should check with L0 and Mesa
about this.

Also about whether UMD's need or want the header itself. For OA, UMD's were
happy not having to parse the header.

> +	/** @flags: flags */
> +	__u16 flags;
> +/* EU stall data dropped by the HW due to memory buffer being full */
> +#define XE_EU_STALL_FLAG_OVERFLOW_DROP	(1 << 0)

In OA such information is returned via DRM_XE_OBSERVATION_IOCTL_STATUS. For
EU stall, e.g. we could return a bit mask of subslices which reporting
drops. So similar to OA, we could return -EIO when HW reports drops and
userspace optionally issues DRM_XE_OBSERVATION_IOCTL_STATUS to retrieve
which subslices are reporting drops.

> +	/** @record_size: size of each EU stall data record */
> +	__u16 record_size;

This is static information. Does it need to be in each packet header?
E.g. it can be returned via DRM_XE_OBSERVATION_IOCTL_INFO after a EU Stall
stream has been opened.

The INFO data struct could also include a capabilities field. So if new
features are added to EU stall in the future, they would be advertized to
user space using the capabilities field.

> +	/** @num_records: number of records following the header */
> +	__u16 num_records;

This will not be needed if just return raw EU Stall data without
headers. Or even otherwise it is probably not needed, it is the total size
of returned data minus the size of the header. Provided we return all
available data.

> +	/** @reserved: Reserved */
> +	__u16 reserved[4];

This can be handled via 'extensions'. And if headers change they can be
advertized in capabilities.

> +};
> +
>  #if defined(__cplusplus)
>  }
>  #endif
> --
> 2.41.0
>

Thanks.
--
Ashutosh

  parent reply	other threads:[~2024-08-16 22:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-07 22:41 [PATCH v2 0/1] Add support for EU stall sampling Ashutosh Dixit
2024-07-07 22:41 ` [PATCH v2 1/1] drm/xe/eustall: " Ashutosh Dixit
2024-07-12 20:34   ` Souza, Jose
2024-07-19 20:21   ` Souza, Jose
2024-08-26 17:32     ` Harish Chegondi
2024-08-16 22:37   ` Dixit, Ashutosh [this message]
2024-08-21 19:35     ` Cabral, Matias A
2024-08-22 22:53       ` Dixit, Ashutosh
2024-08-23 13:09         ` Souza, Jose
2024-08-23 19:24           ` Dixit, Ashutosh
2024-08-23 21:22         ` Souza, Jose
2024-08-26 16:48           ` Dixit, Ashutosh
2024-08-26 17:31             ` Cabral, Matias A
2024-08-30  6:20               ` Harish Chegondi
2024-08-30  8:24                 ` Ranjan, Joshua Santhosh
2024-08-30 15:58                   ` Cabral, Matias A
2024-08-30 20:31                     ` Harish Chegondi
2024-08-22 23:41   ` Matt Roper
2024-07-07 22:46 ` ✓ CI.Patch_applied: success for Add support for EU stall sampling (rev2) Patchwork
2024-07-07 22:46 ` ✗ CI.checkpatch: warning " Patchwork
2024-07-07 22:47 ` ✓ CI.KUnit: success " Patchwork
2024-07-07 22:59 ` ✓ CI.Build: " Patchwork
2024-07-07 23:02 ` ✗ CI.Hooks: failure " Patchwork
2024-07-07 23:03 ` ✓ CI.checksparse: success " Patchwork
2024-07-07 23:22 ` ✓ CI.BAT: " Patchwork
2024-07-08  0:25 ` ✗ CI.FULL: failure " Patchwork
2024-07-19 21:32 ` [PATCH v2 0/1] Add support for EU stall sampling Umesh Nerlige Ramappa

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=878qww3xh8.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=felix.j.degrood@intel.com \
    --cc=harish.chegondi@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jose.souza@intel.com \
    --cc=matias.a.cabral@intel.com \
    --cc=umesh.nerlige.ramappa@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