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 56812E9E31B for ; Wed, 11 Feb 2026 15:14:55 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B902410E611; Wed, 11 Feb 2026 15:14:54 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=collabora.com header.i=@collabora.com header.b="Z08UDo1c"; dkim-atps=neutral Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) by gabe.freedesktop.org (Postfix) with ESMTPS id 798D510E008 for ; Wed, 11 Feb 2026 15:14:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770822890; bh=YRzcqEBr0qJ12+c4/OLqbSNQArzU/f1hg6aTnAmPMHk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Z08UDo1cYNEadsvuKRz4Jtdfuj7fNbW8g+ohXksUnEkk8E67A3SXKhZSSmhV9KBxC WTwbvU2PosN6zyjYHzHseHIjTGAIp59sqo2qg4sXVyhnedRw5eAPLloACiiz/8oZMi 9GO0t7/6/fG+i+RZ9ZHF26BBOlr3F673S+ygKKg/O5eqgQ9nrFy0N5nb57JY1UqzkB 1ufhBu4R2BsFgRcslTW/LhAno4YNY1/MyJK4fZ3fRdlA//wiO+52PUCzSnhZSIIVXS X5fc5V3R/WFsQfGkejkA2LkBwxfJySp/kXj0Ghi/+2NVBZ6kap9E3pxwic7swnFnwr bPAAKQPiLJ1kg== Received: from fedora (unknown [IPv6:2a01:e0a:2c:6930:d919:a6e:5ea1:8a9f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 1697B17E009B; Wed, 11 Feb 2026 16:14:50 +0100 (CET) Date: Wed, 11 Feb 2026 16:14:44 +0100 From: Boris Brezillon To: "Danilo Krummrich" Cc: "Alice Ryhl" , Christian =?UTF-8?B?S8O2bmln?= , "Philipp Stanner" , , "David Airlie" , "Simona Vetter" , "Gary Guo" , "Benno Lossin" , "Daniel Almeida" , "Joel Fernandes" , , , , , , Subject: Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions Message-ID: <20260211161444.3d170ea1@fedora> In-Reply-To: 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> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, 11 Feb 2026 16:05:48 +0100 "Danilo Krummrich" wrote: > 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: > >> >> I.e. sharing a workqueue between JobQs is fine, but we have to ensure they can't > >> >> be used for anything else. > >> > > >> > Totally agree with that, and that's where I was going with this special > >> > DmaFenceWorkqueue wrapper/abstract, that would only accept > >> > scheduling MaySignalDmaFencesWorkItem objects. > >> > >> Not sure if it has to be that complicated (for a first shot). At least for 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 work on > the (shared) JobQueue workqueue" part. I think drivers can just have a separate > workqueue for such use-cases. Okay, that would be one DmaFenceWorkqueue only used for the driver JobQueue instances (or one per-instance if the driver wants that) wrapped into some object that doesn't expose it as a generic workqueue, so only JobQueue instances can use it. And then drivers are free to instantiate their own DmaFenceWorkqueue for anything else that's still in the DMA-signalling path, but not directly related to JobQueues. I think I'd be fine with that.