Improvements to MSI-X API
Hi folks !
A while back, Matthew was mentioning (iirc) some work on improving the MSI-X APIs to be a bit less inflexible, for example by allowing setting up individual MSI-X interrupts independently at runtime.
Is that still something being worked on ?
Another thing I've got poked about by some folks working on a new adapter is that they would like the ability to control aliasing if we cannot provide all the MSI-X. IE. IF the adapter has 16 sources but we can only provide 10, they want the driver to be able to enable all 16, but configure some of them to shoot the same message to the same address.
This is useful in the case where the sources aren't really separate queues but totally different type of messages, to be able to do some fine grained control of what goes where, as the HW doesn't do that sort of aliasing itself.
Cheers,
Ben.
Quoted 15 lines · Benjamin Herrenschmidt
Hi folks !
A while back, Matthew was mentioning (iirc) some work on improving the MSI-X APIs to be a bit less inflexible, for example by allowing setting up individual MSI-X interrupts independently at runtime.
Is that still something being worked on ?
Another thing I've got poked about by some folks working on a new adapter is that they would like the ability to control aliasing if we cannot provide all the MSI-X. IE. IF the adapter has 16 sources but we can only provide 10, they want the driver to be able to enable all 16, but configure some of them to shoot the same message to the same address.
Quoted 4 lines
This is useful in the case where the sources aren't really separate queues but totally different type of messages, to be able to do some fine grained control of what goes where, as the HW doesn't do that sort of aliasing itself.
Note that a way to avoid problems with existing kernels & APIs might be in HW to:
- Have a "mandatory" interrupt (MSI-X entry 0 ?)
- Have the HW route any unconfigured source to that interrupt
IE. Enforce the aliasing.
Cheers,
Ben.