Re: [PATCH 00/11] Enable per exec queue MSI-X vector assignment

[Matthew Brost <matthew.brost@intel.com>]

On Thu, Jun 11, 2026 at 05:08:07PM -0600, Summers, Stuart wrote:
> On Wed, 2026-06-10 at 16:51 -0700, Matthew Brost wrote:
> > On Wed, Jun 10, 2026 at 09:28:32PM +0000, Stuart Summers wrote:
> > > This series adds support for per exec queue MSI-X vector
> > > assignment as well as a per exec queue wait queue in the
> > 
> > There’s another improvement we should consider once we have MSIX per
> > queue: assigning a unique xe_hw_fence_irq to each queue with a valid
> > MSIX vector. In the MSIX IRQ handler, we could map from the vector to
> > q
> > and only trigger that queue’s xe_hw_fence_irq.
> > 
> > This should reduce IRQ overhead, as we would walk the individual
> > queue’s
> > list of pending jobs/fences rather than all pending jobs/fences
> > within
> > an engine class. We could also introduce a variant of
> > hw_fence_irq_run_cb for MSIX that immediately bails when it
> > encounters
> > an unsignaled fence, since the list in xe_hw_fence_irq would now
> > signal
> > in order.
> > 
> > This can be done as a follow-up, but it should provide a significant
> > win
> > in certain cases.
> 
> So I was trying to limit in this first version to compute use cases,
> but maybe you're right we should go ahead and include this for the non-
> lr cases. I'll also review the sync case you mentioned I think in that

LR jobs are now tracked in IRQ handler to support VF migration - so this
suggestion applies to everything now.

> other comment.
> 
> I guess I'd rather keep all of that in this one series. On the one
> hand, I do want to get some of these changes in sooner than later so we
> have this use case aligned with a lot of the SRIOV related changes
> going in here. But also, this isn't such a huge set of changes that it
> should have that much of an impact. I'll take a look and get back if it
> seems like something that should get split.
> 

I'm fine either way as long as someone picks up this suggestion sooner
or later. I suspect my suggestion here will be an overall larger perf win than
this series and shouldn't too difficult to implement.

Matt

> Thanks!
> Stuart
> 
> > 
> > Matt
> > 
> > > wait user fence ioctl. MSI-X vectors are dynamically assigned
> > > during exec queue creation up to a set maximum. Once the max
> > > is reached, everything else falls back to the default vector.
> > 
> > > 
> > > These dynamic vectors allow us to wake up a targeted wait
> > > queue and user thread instead of broadcasting out to all
> > > potential user threads like we're doing today. This is interesting
> > > when we have many user threads outstanding as we don't want
> > > to wake them up in a storm for each interrupt coming in.
> > > 
> > > Additionally, there have been changes in the memirq code lately
> > > to isolate some of the interrupts handled here. Starting with
> > > xe3p, however, we have new interrupts available for compute walker
> > > post sync interrupts. Currently these are enabled for legacy MSI
> > > use cases, but the bits are also available for MSI-X. Enable
> > > those bits here.
> > > 
> > > v2: Drop the drm_dbg change patch
> > >     Directly call xe_hw_engine_handle_irq() from
> > > xe_memirq_hwe_handler()
> > >     Only add to ufence_list for user queues
> > > 
> > > Stuart Summers (11):
> > >   drm/xe: Add kerneldoc to xe_wait_user_fence_ioctl()
> > >   drm/xe: Handle NULL in xe_exec_queue_get_unless_zero()
> > >   drm/xe: Cap MSI-X vector count to XE_MSIX_MAX_VECS
> > >   drm/xe: Assign dedicated MSI-X vectors to exec queues
> > >   drm/xe: Add configfs max_msix_vecs attribute
> > >   drm/xe: Remove memirq status and source checks for engine
> > > interrupts
> > >   drm/xe: Add per-exec-queue user fence wait queue
> > >   drm/xe: Track all exec queues in a device-level ufence list
> > >   drm/xe: Hook up per queue thread wake to the unique MSI-X vector
> > >     allocation
> > >   drm/xe: Enable per-queue ufence wake in ioctl and wake function
> > >   drm/xe/memirq: Enable compute walker post-sync interrupt
> > > 
> > >  drivers/gpu/drm/xe/regs/xe_lrc_layout.h  |  3 +
> > >  drivers/gpu/drm/xe/xe_configfs.c         | 71
> > > ++++++++++++++++++++++++
> > >  drivers/gpu/drm/xe/xe_configfs.h         |  6 ++
> > >  drivers/gpu/drm/xe/xe_device.c           |  2 +
> > >  drivers/gpu/drm/xe/xe_device_types.h     | 11 ++++
> > >  drivers/gpu/drm/xe/xe_exec_queue.c       | 51 ++++++++++++++++-
> > >  drivers/gpu/drm/xe/xe_exec_queue.h       |  2 +-
> > >  drivers/gpu/drm/xe/xe_exec_queue_types.h |  6 ++
> > >  drivers/gpu/drm/xe/xe_guc_submit.c       |  6 +-
> > >  drivers/gpu/drm/xe/xe_hw_engine.c        |  6 +-
> > >  drivers/gpu/drm/xe/xe_hw_engine.h        |  3 +-
> > >  drivers/gpu/drm/xe/xe_irq.c              | 36 ++++++++++--
> > >  drivers/gpu/drm/xe/xe_irq.h              |  9 +++
> > >  drivers/gpu/drm/xe/xe_lrc.c              | 15 ++++-
> > >  drivers/gpu/drm/xe/xe_memirq.c           | 59 +++++++++-----------
> > >  drivers/gpu/drm/xe/xe_memirq.h           |  4 +-
> > >  drivers/gpu/drm/xe/xe_sync.c             |  3 +-
> > >  drivers/gpu/drm/xe/xe_wait_user_fence.c  | 64
> > > ++++++++++++++++++++-
> > >  drivers/gpu/drm/xe/xe_wait_user_fence.h  |  4 ++
> > >  19 files changed, 310 insertions(+), 51 deletions(-)
> > > 
> > > -- 
> > > 2.43.0
> > > 
>