On Tue, 2026-02-10 at 15:57 +0100, Boris Brezillon wrote: > On Tue, 3 Feb 2026 09:14:02 +0100 > Philipp Stanner <[email protected]> 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. 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. P.
