On Wed, 11 Feb 2026 11:47:27 +0100 Philipp Stanner <[email protected]> wrote:
> 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. 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.
