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 1FF37D711DE for ; Wed, 20 Nov 2024 18:40:39 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E055210E115; Wed, 20 Nov 2024 18:40:38 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="ftJAL3NO"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by gabe.freedesktop.org (Postfix) with ESMTPS id E264B10E115 for ; Wed, 20 Nov 2024 18:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1732128038; x=1763664038; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=8C6bpIshml00K5NfIxDB8WuAy5tMFq9IvtGCdM9Gr2o=; b=ftJAL3NO/DeruOZFqs+uFhw7UYRckNPIzPPVb/Yr/RCeIqA4FZriVIx+ oX2GERoAea0Cqe1/Thkj/EhDpPItDrTr8QPGBPX1WAPvldGGkMyJDjE1O Y1c+dUdEPDKjGUyAcc9FGfImka83kFWrGewge5Dr21y4q3WcNffp955s4 Vy7aJm7EQY1FI0dAP56KoSn8psEjwQLL26A9R7w0ct48jN9wyYHC54u4z yIjnJ0NcOYHllYuF2jKDitGEEc/M9sDJKYbrthF+zneiiiNCqCKs8hc11 TmG1besH9MxQN3ps10IvzM5TeUk5tsYTZwF7fc/uHlbUyaLhOrjiDC6RO A==; X-CSE-ConnectionGUID: bAH8epqjRiu/jQlGCWKx9Q== X-CSE-MsgGUID: kdo2abbOTWOGoekRejThiw== X-IronPort-AV: E=McAfee;i="6700,10204,11262"; a="54706712" X-IronPort-AV: E=Sophos;i="6.12,170,1728975600"; d="scan'208";a="54706712" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2024 10:40:38 -0800 X-CSE-ConnectionGUID: El6qlqvQRoGYbh6cCzWJWg== X-CSE-MsgGUID: r2sNtjuuSvyplzpEniYmlg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,170,1728975600"; d="scan'208";a="95070587" Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com) ([10.165.21.142]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Nov 2024 10:40:37 -0800 Date: Wed, 20 Nov 2024 10:40:37 -0800 Message-ID: <8534jllpei.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Harish Chegondi Cc: intel-xe@lists.freedesktop.org, james.ausmus@intel.com, felix.j.degrood@intel.com, jose.souza@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, Umesh Nerlige Ramappa Subject: Re: [PATCH v5 2/7] drm/xe/eustall: Introduce API for EU stall sampling In-Reply-To: References: <12a7988ff01a7b32a9705abd121f0b20a551673b.1731919693.git.harish.chegondi@intel.com> <85zflwwer2.wl-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/28.2 (x86_64-redhat-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 Tue, 19 Nov 2024 20:59:57 -0800, Harish Chegondi wrote: > > > > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h > > > index 4a8a4a63e99c..80aaa5b50c8a 100644 > > > --- a/include/uapi/drm/xe_drm.h > > > +++ b/include/uapi/drm/xe_drm.h > > > @@ -1397,6 +1397,8 @@ struct drm_xe_wait_user_fence { > > > enum drm_xe_observation_type { > > > /** @DRM_XE_OBSERVATION_TYPE_OA: OA observation stream type */ > > > DRM_XE_OBSERVATION_TYPE_OA, > > > + /** @DRM_XE_OBSERVATION_TYPE_EU_STALL: EU stall sampling observation stream type */ > > > + DRM_XE_OBSERVATION_TYPE_EU_STALL, > > > }; > > > > > > /** > > > @@ -1713,6 +1715,43 @@ struct drm_xe_oa_stream_info { > > > __u64 reserved[3]; > > > }; > > > > > > +/** > > > + * enum drm_xe_eu_stall_property_id - EU stall sampling input property ids. > > > + * > > > + * These properties are passed to the driver at open as a chain of > > > + * @drm_xe_ext_set_property structures with @property set to these > > > + * properties' enums and @value set to the corresponding values of these > > > + * properties. @drm_xe_user_extension base.name should be set to > > > + * @DRM_XE_EU_STALL_EXTENSION_SET_PROPERTY. > > > + * > > > + * With the file descriptor obtained from open, user space must enable > > > + * the EU stall stream fd with @DRM_XE_OBSERVATION_IOCTL_ENABLE before > > > + * calling read. > > > > Good to add this. Maybe also add "EIO return from read() indicates buffer > > overflow" since EIO return is part of uapi. > Can I add a comment block on EU stall sampling above the comment block > for this structure? While it is important to document read() returning > -EIO for buffer overflow, I am wondering if this is the correct place to > add the comment since it is unrelated to the below structure? There don't seem to be any such comment blocks in this file. So no need to overthink this, just add a line about EIO right here and be done with it. > > > + */ > > > +enum drm_xe_eu_stall_property_id { > > > +#define DRM_XE_EU_STALL_EXTENSION_SET_PROPERTY 0 > > > + /** > > > + * @DRM_XE_EU_STALL_PROP_SAMPLE_RATE: Sampling rate > > > + * in multiples of 251 cycles. Valid values are 1 to 7. > > > + * If the value is 1, sampling interval is 251 cycles. > > > + * If the value is 7, sampling interval is 7 x 251 cycles. > > > + */ > > > + DRM_XE_EU_STALL_PROP_SAMPLE_RATE = 1, > > > > There is an unaddressed comment from Umesh about this (on the previous > > version), we need to address it. > I am still working on the comment from Umesh and seeking feedback from > others including the user space folks. I think having this input as it > is in terms of cycles is more generic and more future proof as the clock > frequency can vary from GPU to GPU and even for a GPU it can vary from > time to time due to performance and power reasons? Will respond to this in the thread where Umesh's original comment is. Ashutosh