Re: [RFC PATCH 3/4] rust/drm: Add DRM Jobqueue

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

On Wed, 11 Feb 2026 11:47:27 +0100
Philipp Stanner <phasta@mailbox.org> wrote:

> On Tue, 2026-02-10 at 15:57 +0100, Boris Brezillon wrote:
> > On Tue,  3 Feb 2026 09:14:02 +0100
> > Philipp Stanner <phasta@kernel.org> wrote:
> >   
> > > +/// A jobqueue Job.
> > > +///
> > > +/// You can stuff your data in it. The job will be borrowed back to your driver
> > > +/// once the time has come to run it.
> > > +///
> > > +/// Jobs are consumed by [`Jobqueue::submit_job`] by value (ownership transfer).
> > > +/// You can set multiple [`DmaFence`] as dependencies for a job. It will only
> > > +/// get run once all dependency fences have been signaled.
> > > +///
> > > +/// Jobs cost credits. Jobs will only be run if there are is enough capacity in
> > > +/// the jobqueue for the job's credits. It is legal to specify jobs costing 0
> > > +/// credits, effectively disabling that mechanism.
> > > +#[pin_data]
> > > +pub struct Job<T: 'static + Send> {
> > > +    cost: u32,
> > > +    #[pin]
> > > +    pub data: T,
> > > +    done_fence: Option<ARef<DmaFence<i32>>>,
> > > +    hardware_fence: Option<ARef<DmaFence<i32>>>,
> > > +    nr_of_deps: AtomicU32,
> > > +    dependencies: List<Dependency>,  
> > 
> > Given how tricky Lists are in rust, I'd recommend going for an XArray,
> > like we have on the C side. There's a bit of overhead when the job only
> > has a few deps, but I think simplicity beats memory-usage-optimizations
> > in that case (especially since the overhead exists and is accepted in
> > C).  
> 
> I mean, the list is now already implemented and works. Considering the
> XArray would have made sense during the development difficulties.

I'm sure it does, but that's still more code/tricks to maintain than
what you'd have with the XArray abstraction.

> 
> If it were to make sense we could certainly replace the list with an
> xarray, but I don't see an advantage. The JQ just needs to iterate over
> the dependencies to register its events on them, and on drop to
> deregister them perhaps.
> 
> We have many jobs, but likely only few dependencies per job, so the
> lower memory footprint seems desirable and the XArray's advantages
> don't come to play – except maybe if we'd want to consider to avoid the
> current unsafe-rawpointer solution to obtain the job, since obtaining a
> job from an Xarray is far faster than by list iteration.

I don't think we need O(1) for picking random deps in a job, because
that's not something we need at all: the dep list here is used as a
FIFO. There's the per-dep overhead of the ListLinks object maybe, but
it's certainly acceptable. And I don't think cache locality matters
either, because the XArray stores pointers too, so we'll still be one
deref away from the DmaFence. No, my main concern was maintainability,
because managing lists in rust is far from trivial, and as a developer,
I try to avoid using concepts the language I rely on is not friendly
with.