Re: change MSI/MSI-X APIs

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

I'm sorry for late reply.

On 2015/05/31 6:45, David Laight wrote:
> On Mon, May 11, 2015 at 03:15:25PM +0900, Kengo NAKAHARA wrote:
>> Hi,
>>
>> I received feedback from some device driver authors. They point out
>> establish, disestablish and release APIs should be unified for INTx,
>> MSI and MSI-X. So, I would change the APIs as below:
> 
> Some more feedback...
> 
> PCIe devices that only support MSI-X could have support for very
> large numbers of interrupts.
> 
> Some might only be needed if a specific function is used,
> or might only be used to load sharing (eg multi-q ethernet).
> In either case you might want to allocate some of the MSI-X
> vectors at driver load time, and allocate others at a much later
> time.
> IIRC nothing in the hardware spec stops you doing this.
> 
> Theoretically you could allocate the MSI-X vector (etc)
> when the interrupt is enabled, and dealloacate on disable
> (apart from timing problems on the hardware).
> I'm not suggesting you go that far!
> 
> This would also make it less likely that interrupts won't
> be available for drivers that initialise later on.

Theoretically yes, but I think it is less benefit in spite of the
complex implementation.
# e.g. error handling code and fallback code to MSI or INTx

Since MSI-X vectors are device specific resources, the other devices 
which are initialized later can allocate MSI-X vectors independently
from the devices initialized before.
Of course, the device allocates a bit of memory when it call
pci_msi{,x}_alloc APIs. However, the amount of memory is little, so
I think there is only few cases which the later initialized devices
can be available by allocating MSI-X vectors at enabling interrupt
time.


Thanks,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>