From: David Daney
> Sent: 27 March 2017 18:31
> On 03/27/2017 10:11 AM, Christoph Hellwig wrote:
> > On Mon, Mar 27, 2017 at 09:59:35AM -0700, David Daney wrote:
> >> On 03/27/2017 01:29 AM, Christoph Hellwig wrote:
> >>> Unused now that all callers switched to pci_alloc_irq_vectors.
> >>>
> >>
> >> And you are aware that the ThunderX GPIO driver that I am attempting to
> >> merge uses this interface.
> >>
> >> If this patch gets merged, should I ask to revert it when the GPIO driver
> >> goes in?
> >
> > No. You should not use pci_enable_msix in your new driver as I told
> > you before.
> >
> >> You offer no solution for drivers that would benefit from using a sparse
> >> sub set of the available MSI-X vectors.
> >
> > Use pci_enable_msix_{exact,range} for now, as I told you before.
> >
>
> That still results in twice as many MSI-X being provisioned than are needed.
>
> For drivers that use a contiguous range of MSI-X, your suggestion is
> usable, but for others you are forcing resources to be wasted. For what
> end?
There are also drivers that only need some interrupts after a specific
device is opened, and could free them when closed.
This could even be network devices with lots of queues, or a driver
realising that the workload is high and per-cpu interrupts make sense.
So any real change to the interface should allow drivers to allocate
and free individual MSI-X vectors.
I remember a lot of discussions when pci_enable_msix_range() was added,
but almost nothing about this change.
David
