Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions

[Boris Brezillon <boris.brezillon@collabora.com>]

On Wed, 11 Feb 2026 16:05:48 +0100
"Danilo Krummrich" <dakr@kernel.org> 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" <dakr@kernel.org> 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" <dakr@kernel.org> 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.