From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Harish Chegondi <harish.chegondi@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <james.ausmus@intel.com>,
<felix.j.degrood@intel.com>, <matias.a.cabral@intel.com>,
<joshua.santosh.ranjan@intel.com>, <shubham.kumar@intel.com>,
<matthew.d.roper@intel.com>, <matthew.olson@intel.com>
Subject: Re: [PATCH v6 6/7] drm/xe/uapi: Add a device query to get EU stall sampling information
Date: Tue, 17 Dec 2024 12:07:49 -0800 [thread overview]
Message-ID: <855xni2huy.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <6e104a81ccf931e55a577ce816e5821aab57bec4.1734427624.git.harish.chegondi@intel.com>
On Tue, 17 Dec 2024 01:46:56 -0800, Harish Chegondi wrote:
>
Hi Harish,
Only reviewing the uapi, not the implementation.
> User space can get the EU stall data record size, EU stall capabilities,
> EU stall sampling rates, and per XeCore buffer size with query IOCTL
> DRM_IOCTL_XE_DEVICE_QUERY with .query set to DRM_XE_DEVICE_QUERY_EU_STALL.
> A struct drm_xe_query_eu_stall will be returned to the user space along
> with an array of supported sampling rates sorted in the fastest sampling
> rate first order. sampling_rates in struct drm_xe_query_eu_stall will
> point to the array of sampling rates.
>
> Any capabilities in EU stall sampling as of this patch are considered
> as base capabilities. Any new capabilities added later will need
> a new capabilities flag.
s/a new capabilities flag/new capability bits/. Or, better to say something
like "New capability bits will be added for any new functionality added
later".
See OA capability bits in the latest drm-tip.
>
> v6: Include EU stall sampling rates information and
> per XeCore buffer size in the query information.
/snip/
> diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> index 4ee3b04a1bb5..40c2d274473e 100644
> --- a/include/uapi/drm/xe_drm.h
> +++ b/include/uapi/drm/xe_drm.h
> @@ -700,6 +700,7 @@ struct drm_xe_device_query {
> #define DRM_XE_DEVICE_QUERY_ENGINE_CYCLES 6
> #define DRM_XE_DEVICE_QUERY_UC_FW_VERSION 7
> #define DRM_XE_DEVICE_QUERY_OA_UNITS 8
> +#define DRM_XE_DEVICE_QUERY_EU_STALL 9
> /** @query: The type of data to query */
> __u32 query;
>
> @@ -1770,6 +1771,40 @@ enum drm_xe_eu_stall_property_id {
> DRM_XE_EU_STALL_PROP_EVENT_REPORT_COUNT,
> };
>
> +/**
> + * struct drm_xe_query_eu_stall - Information about EU stall sampling.
> + *
> + * If a query is made with a struct @drm_xe_device_query where .query
> + * is equal to @DRM_XE_DEVICE_QUERY_EU_STALL, then the reply uses
> + * struct @drm_xe_query_eu_stall in .data.
> + */
> +struct drm_xe_query_eu_stall {
> + /** @extensions: Pointer to the first extension struct, if any */
> + __u64 extensions;
> +
> + /** @capabilities: EU stall capabilities bit-mask */
> + __u64 capabilities;
> +#define DRM_XE_EU_STALL_CAPS_BASE (1 << 0)
> +
> + /** @record_size: size of each EU stall data record */
> + __u64 record_size;
> +
> + /** @per_xecore_buf_size: Per XeCore buffer size */
> + __u64 per_xecore_buf_size;
This new member has appeared. What is its purpose and how will userspace
use it? Basically how is it relevant?
> +
> + /** @num_sampling_rates: Number of sampling rates supported */
> + __u64 num_sampling_rates;
> +
> + /**
> + * @sampling_rates: Pointer to an array of sampling rates
> + * sorted in the fastest sampling rate first order.
sorted from fastest to slowest.
> + */
> + __u64 *sampling_rates;
This should be written as a flexible array as follows:
__u64 sampling_rates[];
So sampling rate array is just present at the end of the struct, there
should be no separate pointer here in the struct.
https://en.wikipedia.org/wiki/Flexible_array_member
Also we need to document what units the sampling rates are in. So something
like "Sampling rates are specified in number of cycles of the reference
clock".
So we have decided not to use nanoseconds (so sampling period rather than
sampling rate)? Any particular reason for that? Though I am ok either way.
> +
> + /** @reserved: Reserved */
> + __u64 reserved[5];
Because flexible arrays must be the last field in a structure, this
reserved field should be moved before num_sampling_rates field.
> +};
> +
> #if defined(__cplusplus)
> }
> #endif
> --
> 2.47.0
>
Ashutosh
next prev parent reply other threads:[~2024-12-17 20:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 9:46 [PATCH v6 0/7] Add support for EU stall sampling Harish Chegondi
2024-12-17 9:46 ` [PATCH v6 1/7] drm/xe/topology: Add a function to find the index of the last enabled DSS in a mask Harish Chegondi
2024-12-17 9:46 ` [PATCH v6 2/7] drm/xe/uapi: Introduce API for EU stall sampling Harish Chegondi
2024-12-17 20:35 ` Dixit, Ashutosh
2024-12-18 22:51 ` Harish Chegondi
2024-12-19 16:27 ` Dixit, Ashutosh
2024-12-19 20:29 ` Harish Chegondi
2024-12-19 20:53 ` Raag Jadav
2024-12-19 20:54 ` Dixit, Ashutosh
2024-12-17 9:46 ` [PATCH v6 3/7] drm/xe/eustall: Implement EU stall sampling APIs for Xe_HPC Harish Chegondi
2024-12-17 9:46 ` [PATCH v6 4/7] drm/xe/eustall: Return -EIO error from read() if HW drops data Harish Chegondi
2024-12-17 9:46 ` [PATCH v6 5/7] drm/xe/eustall: Add EU stall sampling support for Xe2 Harish Chegondi
2024-12-17 9:46 ` [PATCH v6 6/7] drm/xe/uapi: Add a device query to get EU stall sampling information Harish Chegondi
2024-12-17 20:07 ` Dixit, Ashutosh [this message]
2024-12-18 23:24 ` Harish Chegondi
2024-12-19 16:36 ` Dixit, Ashutosh
2024-12-19 20:04 ` Harish Chegondi
2024-12-19 20:15 ` Dixit, Ashutosh
2024-12-19 20:19 ` Dixit, Ashutosh
2024-12-17 9:46 ` [PATCH v6 7/7] drm/xe/eustall: Add workaround 22016596838 which applies to PVC Harish Chegondi
2024-12-17 15:35 ` ✓ CI.Patch_applied: success for Add support for EU stall sampling Patchwork
2024-12-17 15:35 ` ✗ CI.checkpatch: warning " Patchwork
2024-12-17 15:37 ` ✓ CI.KUnit: success " Patchwork
2024-12-17 15:55 ` ✓ CI.Build: " Patchwork
2024-12-17 15:57 ` ✗ CI.Hooks: failure " Patchwork
2024-12-17 15:58 ` ✓ CI.checksparse: success " Patchwork
2024-12-17 16:32 ` ✓ Xe.CI.BAT: " Patchwork
2024-12-18 0:47 ` ✗ Xe.CI.Full: failure " Patchwork
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=855xni2huy.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=james.ausmus@intel.com \
--cc=joshua.santosh.ranjan@intel.com \
--cc=matias.a.cabral@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=matthew.olson@intel.com \
--cc=shubham.kumar@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.