RE: [patch 21/32] NTB/msi: Convert to msi_on_each_desc()

From: Thomas Gleixner <redacted>
Sent: Thursday, December 9, 2021 11:58 PM

On Thu, Dec 09 2021 at 12:17, Kevin Tian wrote:

quoted

quoted

From: Thomas Gleixner <redacted>
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.

quoted

quoted

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'

quoted

quoted

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

quoted

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