> From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Sent: Thursday, December 9, 2021 11:58 PM > > On Thu, Dec 09 2021 at 12:17, Kevin Tian wrote: > >> From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > >> 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,.....) > > > > Not exactly IMS-ENTRY. MSI-ENTRY also works. > > Sure. > > >> > >> 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. > > > > While it's one way of looking at this model do we want to actually > > create some objects to represent this 'virtual queue' concept? that > > implies each ENQCMD must be moderated to create such short-lifespan > > objects and I'm not sure the benefit of doing so. > > You don't have to create anything. The PASID/ENTRY pair represents that > 'virtual queue', right? Yes > > > If not then from driver p.o.v it's still one queue resource and driver > > needs to manage its association with multiple interrupt entries and > > PASIDs when it's connected to multiple clients. > > That's correct, but there is nothing problematic with it. It's like > allocating multiple interrupts for any other hardware device or > subdevice, right? No question on this. Just want to point out such usage example since Jason mentioned it. 😊 > > What's probably more interresting is how the PASID/interrupt/RID > relations are managed. > yes, that's something we need further think of. Thanks Kevin
