On Wed, 11 Feb 2026 16:05:48 +0100 "Danilo Krummrich" <[email protected]> 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" <[email protected]> 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" <[email protected]> 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.
