Messages in this thread | | | From | Thomas Gleixner <> | Subject | RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc() | Date | Thu, 09 Dec 2021 10:03:00 +0100 |
| |
Kevin,
On Thu, Dec 09 2021 at 06:26, Kevin Tian wrote: >> From: Jason Gunthorpe <jgg@nvidia.com> >> 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.
I think you are looking at that from the internal implementation details of IDXD. But you can just model it in an IDXD implementation agnostic way:
ENQCMD(PASID, IMS-ENTRY,.....)
implies an on demand allocation of a virtual queue, which is deallocated when the command completes. The PASID and IMS-ENTRY act as the 'queue' identifier.
The implementation detail of IDXD that it executes these computations on an internal shared workqueue does not change that.
Such a workqueue can only execute one enqueued command at a time, which means that during the execution of a particular command that IDXD internal workqueue represents the 'virtual queue' which is identified by the unique PASID/IMS-ENTRY pair.
No?
Thanks,
tglx
| |