Re: [PATCH v3 1/2] sched_ext: Add dispatch transaction API

[Andrea Righi <arighi@nvidia.com>]

On Sun, May 10, 2026 at 04:02:33AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Sat, May 09, 2026 at 11:24:12PM +0200, Andrea Righi wrote:
> > Why not passing slice to scx_bpf_dsq_insert_commit()? Is it because of the BPF
> > args limitation? In that case we could introduce a struct similar to
> > scx_bpf_dsq_insert_vtime_args.
> > 
> > Speaking of vtime, we may also need a scx_bpf_dsq_insert_vtime_commit() that
> > accepts dsq_vtime as well, otherwise how do we use priority DSQs with this new
> > transaction variant?
> 
> Given that these are only meaningful when targeting local DSQs, I don't
> think vtime interface is necessary. It'd probably be a good idea to
> explicitly restrict usage to local DSQs.

Ack, it definitely makes sense to restrict this to local DSQs.

> 
> > > To support explicit token passing, rename scx_dsq_insert_commit() to
> > > scx_dsq_insert_buf() and add a qseq parameter. All existing callers
> > > preserve the original behavior.
> > > 
> > > This mechanism is intended for schedulers that do not implement
> > > properly synchronized dequeue. A scheduler whose ops.dequeue()
> > > synchronizes atomically with the dispatch path does not need this API.
> > 
> > I'm wondering if we should validate qseq also in mark_direct_dispatch(), it
> > seems that we're not validating qseq in the direct dispatch path, or am I
> > missing something?
> 
> In DD path, the task can't be lost and it'd be a bit silly to use this
> interface. Again, probably good idea to at least start with just allowing in
> dispatch path.

Also true. Thanks for clarifying.

-Andrea