[lkml]   [2021]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()
> From: Jason Gunthorpe <>
> Sent: Saturday, December 4, 2021 12:41 AM
> > Or has each queue and controlblock and whatever access to a shared large
> > array where the messages are stored and the indices are handed out to
> > the queues and controlblocks?
> > If each of them have their own small array, then queue relative indexing
> > makes a ton of sense, no?
> Okay, I see.
> I don't know of any use case for more than one interrupt on a queue,
> and if it did come up I'd probably approach it by making the queue
> handle above also specify the 'queue relative HW index'

We have such use case with IDXD.

Basically the IDXD queue allows software to put an interrupt handle
(the index of MSI-X or IMS entry) in the submitted descriptor. Upon
completion of the descriptor the hardware finds the specified entry
and then generate interrupt to notify software.

Conceptually descriptors submitted to a same queue can use different
handles, implying one queue can be associated to multiple interrupts.

One example is the shared work queue usage which allows multiple
clients directly and simultaneously submitting descriptors to the
same queue, by using ENQCMD(pasid, descriptor) instruction. In this
case each client can be allocated with an interrupt entry (including the
information about the client's pasid for permission check when the
HW generates completion interrupt) and then use this entry for
all descriptors submitted by that client.

Haven't completed reading of this thread, but would like to point
out this usage so it is not ignored in the final rework. It basically
means one queue might be associated to multiple interrupt entries
and multiple pasids. 😊

 \ /
  Last update: 2021-12-09 07:27    [W:0.193 / U:1.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site