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 1F464D149E7 for ; Fri, 25 Oct 2024 19:45:54 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D3CFB10E0D9; Fri, 25 Oct 2024 19:45:53 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="f2iSGYVg"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2787910E0D9 for ; Fri, 25 Oct 2024 19:45:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1729885553; x=1761421553; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=nES5SuZsjlhrs11IbIhb1hdeKanoRXcGGMV/bxfnhKw=; b=f2iSGYVgCW1GbRRiJmiedBCly8Qd1Xln6+7qpRaEWRYWmVXbs8V+9cWZ Uupw/ieFgOdpAq2ZN8fjN6O6qmObfCVRygEmYPD32Q9FE+bMZyNZ18jZv 2DY4BYax9ih0ElPyz/XSiqzx72hVKPjCKHBBQARJzE0iASdiVo+JBfQ/4 bvvuZKcnfk39tWvN7s7FgQYSpKXNW6pNk+1GDahqDWlAZW9u/70HAB8+O AnggxnwDrIofrzgo+TUCcbOUVbMH1dkzDjV59Kr1/VEVndLV9NUMIz9Kh GwSYuu+jYR9mcvLydggTzwwxzlwN1Y+e9eSzwHjBOzi8r5Sx/3obT/5a+ Q==; X-CSE-ConnectionGUID: uBN81Z1mRtmQninfLDpC2w== X-CSE-MsgGUID: +EMo4CP8SKOKWldGK+iIDQ== X-IronPort-AV: E=McAfee;i="6700,10204,11222"; a="40668943" X-IronPort-AV: E=Sophos;i="6.11,199,1725346800"; d="scan'208";a="40668943" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Oct 2024 12:45:52 -0700 X-CSE-ConnectionGUID: wryaq8thR8KULPMaMif3lw== X-CSE-MsgGUID: lx6M4ri2RWKDgLcGMKoW0A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,232,1725346800"; d="scan'208";a="85794214" Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com) ([10.165.21.142]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Oct 2024 12:45:52 -0700 Date: Fri, 25 Oct 2024 12:45:51 -0700 Message-ID: <858quct18w.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa Cc: igt-dev@lists.freedesktop.org Subject: Re: [PATCH i-g-t 2/2] tests/intel/xe_oa: Tests for OA syncs In-Reply-To: References: <20241025185205.1327235-1-ashutosh.dixit@intel.com> <20241025185205.1327235-3-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: igt-dev@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development mailing list for IGT GPU Tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" On Fri, 25 Oct 2024 12:35:35 -0700, Umesh Nerlige Ramappa wrote: > Hi Umesh, > On Fri, Oct 25, 2024 at 11:52:05AM -0700, Ashutosh Dixit wrote: > > Verify OA syncs signal correctly in open and change config code > > paths. Verify with different types of sync objects as well as by both > > waiting and skipping the wait for syncs to signal. > > > > v2: Significantly expand oa syncs testing as described above > > Are we just enabling output sync for the OA use case, as in, user can only > wait for the OA configuration to complete, but cannot control when the OA > config starts? No, both input and output syncs are implemented in the kernel. But this patch only adds tests for the output syncs. I am tracking writing tests for input syncs elsewhere. Input syncs are also straightforward, xe_sync_entry_add_deps() basically does that for you, you just need to call that function from the right place. The output sync's are quite tricky and I have fixed many uaf bugs with these tests. > Which is what existed earlier, so it should be fine either ways. You need both input and output syncs for it to be useful (that allows pipelining the workload while keeping it sync'd with a particular OA config). Mesa is using and have tested both. > > LGTM, > > Reviewed-by: Umesh Nerlige Ramappa Thanks. -- Ashutosh