From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1020C295DB8; Wed, 11 Feb 2026 15:05:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770822354; cv=none; b=omoiBB5IF1/hfSpAsSU81tR0kUEJTqV9EQelChBRbYFCqCxbZpxZB1Pl2mSRAxTgtk3ukabLjHwTVRQo3g+ko7Lp+icWaJQKGw3ef/FpDCNAU4UhCwNzXDLQmKoSDPTbzyUMTbH1p80qQBHewi6xJtn8HlsR4zwp/a9MDbVQr20= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770822354; c=relaxed/simple; bh=ScbyhUmnF5OgA8EcbauwwMYSqHxJsLpyDEnuR07pqz8=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=KFYMKkT8B4sGH/8TGK2TAqYavOhZtuzbK1Ln9iakqpawc1rYPSTRrQYH/3yX/6L1E+8HKH/xrxcGB7Uyurdg+cMQEjLyMgcwEias0sDlOjD7GXfhCVwqgpjVxjclvk5C6bNJRdIWzc0hTtKXf5KFvt5MoIOqpPMWo6RlXfzD6Hw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NuG9WlOO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NuG9WlOO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD4D7C4CEF7; Wed, 11 Feb 2026 15:05:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770822353; bh=ScbyhUmnF5OgA8EcbauwwMYSqHxJsLpyDEnuR07pqz8=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=NuG9WlOOulXVANBtG7VZjS9npHb0LtXRvb4+CFMsVbHJc1x70yAmVyBJ6fdYzc8pG HHjXiYShK5/fMyfgPvlbhyReQS1qQj2W+3sfPNgOIsuushVxzEVqiuFbTJ+oHiwhR9 f8s8RO7BcvI3ip91QgYf3TYrfPVXkDUToVorcLCo95cyPgtC0HThYhtAe6yt+Ittm/ d0hBbiQQU/4Y+GCy7+f020F8ZvjTOHzunEEWpfH/Qfs6R6aJDKeWgJnzzuemce/eG/ 1bd5kWVQbCaY2lsiNzyS0lFDWL385siPaHiP026ZcfKftLCn5EcJXIiZs2+FY9WTam 0APZfVDOubwHQ== Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 11 Feb 2026 16:05:48 +0100 Message-Id: Subject: Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions Cc: "Alice Ryhl" , =?utf-8?q?Christian_K=C3=B6nig?= , "Philipp Stanner" , , "David Airlie" , "Simona Vetter" , "Gary Guo" , "Benno Lossin" , "Daniel Almeida" , "Joel Fernandes" , , , , , , To: "Boris Brezillon" From: "Danilo Krummrich" References: <20260205095727.4c3e2941@fedora> <20260209155843.725dcfe1@fedora> <20260210101525.7fb85f25@fedora> <4e84306c-5cec-4048-a7eb-a364788baa89@amd.com> <20260211112049.089b2656@fedora> <20260211121223.78674f22@fedora> <20260211160059.6e0d3b60@fedora> In-Reply-To: <20260211160059.6e0d3b60@fedora> On Wed Feb 11, 2026 at 4:00 PM CET, Boris Brezillon wrote: > On Wed, 11 Feb 2026 15:38:32 +0100 > "Danilo Krummrich" wrote: > >> On Wed Feb 11, 2026 at 12:12 PM CET, Boris Brezillon wrote: >> > On Wed, 11 Feb 2026 12:00:30 +0100 >> > "Danilo Krummrich" wrote: =20 >> >> I.e. sharing a workqueue between JobQs is fine, but we have to ensure= they can't >> >> be used for anything else. =20 >> > >> > Totally agree with that, and that's where I was going with this specia= l >> > DmaFenceWorkqueue wrapper/abstract, that would only accept >> > scheduling MaySignalDmaFencesWorkItem objects. =20 >>=20 >> Not sure if it has to be that complicated (for a first shot). At least f= or the >> JobQ it would probably be enough to have a helper to create a new, let's= say, >> struct JobQueueWorker that encapsulates a (reference counted) workqueue,= but >> does not give access to it outside of jobq.rs. > > Except we need to schedule some work items that are in the > DMA-signaling path but not directly controlled by the jobq.rs > implementation (see [1] for the post-execution work we schedule in > panthor). > > The two options I can think of are: > > 1. Add a an unsafe interface to schedule work items on the wq attached > to JobQ. Safety requirements in that case being compliance with the > DMA-fence signalling rules. > 2. The thing I was describing before, where we add the concept of > DmaFenceWorkqueue that can only take MaySignalDmaFencesWorkItem. We > can then have a DmaFenceWorkqueue that's global, and pass it to the > JobQueue so it can use it for its own work item. > > We could start with option 1, sure, but since we're going to need to > schedule post-execution work items that have to be considered part of > the DMA-signalling path, I'd rather have these concepts clearly defined > from the start. > > Mind if I give this DmaFenceWorkqueue/MaySignalDmaFencesWorkItem a try > to see what it looks like a get the discussion going from there > (hopefully it's just a thin wrapper around a regular > Workqueue/WorkItem, with an extra dma_fence_signalling annotation in > the WorkItem::run() path), or are you completely against the idea? Not at all, I think it's a good generalization. But I'm very skeptical about the "we allow drivers to schedule arbitrary wo= rk on the (shared) JobQueue workqueue" part. I think drivers can just have a sepa= rate workqueue for such use-cases. > [1]https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/gpu/drm/pant= hor/panthor_sched.c#L1913