From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E0CA9C3DA4A for ; Fri, 16 Aug 2024 22:47:49 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id ADBAD10E853; Fri, 16 Aug 2024 22:47:49 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="JpnuVu4K"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1A64910E853 for ; Fri, 16 Aug 2024 22:47:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1723848468; x=1755384468; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=XFEPiwXT2dUX0iVFWrhI0xgHACceyJmixWJ9Q5SAvQU=; b=JpnuVu4K43u2/Q5QmLbiXS6mhAelTEJmAxdHwc+ytDhjqh+HlEHWU1jx 6LSRLrRaMBofuiW2Pp56U1+gzq4TnR3ycc71PTKcAdrQYm9KoQg07Am1R i3/Z7UYpK1oUg0gXOupQDfDzMtVfqySF3bKfYIf2NSsd7PASoYdy7+H1D 1QdI6X7fGy6Q1NXtZgIqQZQE+wWWC2n9rJ+z32K1BTKWBOFASMdyYDebV 6zp6b0NI5EbnX7KHnWZ5nnsKpS8A/aMwjtTkklFjlak/j5xne0/OvNZrZ SE4UmLTuyXVZ/3MCZLRltoDLH2k0OcQkOaD8z2WxWMSRzDf0yenByLyZ/ g==; X-CSE-ConnectionGUID: zrjYjXHbTsulJGfkgM2SrA== X-CSE-MsgGUID: e0kxN06FSmq+Voi3huPbkg== X-IronPort-AV: E=McAfee;i="6700,10204,11166"; a="21969038" X-IronPort-AV: E=Sophos;i="6.10,153,1719903600"; d="scan'208";a="21969038" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2024 15:47:48 -0700 X-CSE-ConnectionGUID: jyVK5uayRHmfWSe/GB/72w== X-CSE-MsgGUID: HHooAxC1TeWzIu/NnG5KxA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,153,1719903600"; d="scan'208";a="97304273" Received: from rizwanur-mobl1.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.124.52.11]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2024 15:47:47 -0700 Date: Fri, 16 Aug 2024 15:37:55 -0700 Message-ID: <878qww3xh8.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: intel-xe@lists.freedesktop.org Cc: Harish Chegondi , Umesh Nerlige Ramappa , felix.j.degrood@intel.com, Jose Souza , matias.a.cabral@intel.com Subject: Re: [PATCH v2 1/1] drm/xe/eustall: Add support for EU stall sampling In-Reply-To: <20240707224141.2865472-2-ashutosh.dixit@intel.com> References: <20240707224141.2865472-1-ashutosh.dixit@intel.com> <20240707224141.2865472-2-ashutosh.dixit@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" 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