Re: crypto/cavium MSI-X fixups

2017-02-23 Thread Herbert Xu
On Wed, Feb 15, 2017 at 08:18:40AM +0100, Christoph Hellwig wrote:
> Hi George,
> 
> your commit "crypto: cavium - Add Support for Octeon-tx CPT Engine"
> add a new caller to pci_enable_msix.  This API has long been deprecated
> so this series switches it to use pci_alloc_irq_vectors instead.
> 
> Can you please test it and make sure it goes in before the end of the
> merge window so that no more users of the old API hit mainline?

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: crypto/cavium MSI-X fixups

2017-02-22 Thread David Daney

On 02/21/2017 11:27 PM, Christoph Hellwig wrote:

On Tue, Feb 21, 2017 at 09:36:04AM -0800, David Daney wrote:

With respect to pci_enable_msix(), what do you recommend as a replacement?


pci_alloc_irq_vectors.  In fact I have a tree ready for after -rc1
that removes pci_enable_msix() entirely.


I would like to see something that handles the case of this driver that 
I am attempting to get merged:



https://lkml.org/lkml/2017/2/15/1209





For the crypto/cavium driver, you recommend pci_alloc_irq_vectors(), which
works well if the required MSI-X indexes are contiguous starting at zero.
What would be used for a device that has 184 MSI-X, but only a sparse
subset (fewer than half) of these are required for the driver operation.
It would waste system resources to use an API that forces us to allocate
184 when only 80 are required.


Currently we don't have a good API for that.  I've not been through all
users of pci_enable_msix_{range,exact} yet, but so far I've only found
one user not using all vectors from 0 to some limit.  Depending how many
such users we have and how they'll look I will have to look into an API
to support that use case.



See the patch above for the case that doesn't use 0..UPPER_LIMIT

David Daney


Re: crypto/cavium MSI-X fixups

2017-02-21 Thread Christoph Hellwig
On Tue, Feb 21, 2017 at 09:36:04AM -0800, David Daney wrote:
> With respect to pci_enable_msix(), what do you recommend as a replacement?  

pci_alloc_irq_vectors.  In fact I have a tree ready for after -rc1
that removes pci_enable_msix() entirely.

> For the crypto/cavium driver, you recommend pci_alloc_irq_vectors(), which 
> works well if the required MSI-X indexes are contiguous starting at zero.   
> What would be used for a device that has 184 MSI-X, but only a sparse 
> subset (fewer than half) of these are required for the driver operation.  
> It would waste system resources to use an API that forces us to allocate 
> 184 when only 80 are required.

Currently we don't have a good API for that.  I've not been through all
users of pci_enable_msix_{range,exact} yet, but so far I've only found
one user not using all vectors from 0 to some limit.  Depending how many
such users we have and how they'll look I will have to look into an API
to support that use case.


Re: crypto/cavium MSI-X fixups

2017-02-21 Thread David Daney

On 02/19/2017 09:32 AM, Christoph Hellwig wrote:

Herbert,

any comment?  I'd really like to avoid introducing new pci_enable_msix
users in this merge window..


Hi Cristoph,

With respect to pci_enable_msix(), what do you recommend as a 
replacement?  For the crypto/cavium driver, you recommend 
pci_alloc_irq_vectors(), which works well if the required MSI-X indexes 
are contiguous starting at zero.   What would be used for a device that 
has 184 MSI-X, but only a sparse subset (fewer than half) of these are 
required for the driver operation.  It would waste system resources to 
use an API that forces us to allocate 184 when only 80 are required.


Currently pci_enable_msix() allows an arbitrary set of MSI-X to be 
requested, which exactly fits the requirements of our (non 
crypto/cavium) hardware.


Thanks in advance for any insight you can provide,
David Daney




On Wed, Feb 15, 2017 at 02:47:09PM +0530, George Cherian wrote:

Hi Christoph,


On 02/15/2017 12:48 PM, Christoph Hellwig wrote:

Hi George,

your commit "crypto: cavium - Add Support for Octeon-tx CPT Engine"
add a new caller to pci_enable_msix.  This API has long been deprecated
so this series switches it to use pci_alloc_irq_vectors instead.

Can you please test it and make sure it goes in before the end of the
merge window so that no more users of the old API hit mainline?


Yes the changes works well.
Acked-by: George Cherian 

for the series.



---end quoted text---





Re: crypto/cavium MSI-X fixups

2017-02-19 Thread Christoph Hellwig
Herbert,

any comment?  I'd really like to avoid introducing new pci_enable_msix
users in this merge window..

On Wed, Feb 15, 2017 at 02:47:09PM +0530, George Cherian wrote:
> Hi Christoph,
>
>
> On 02/15/2017 12:48 PM, Christoph Hellwig wrote:
>> Hi George,
>>
>> your commit "crypto: cavium - Add Support for Octeon-tx CPT Engine"
>> add a new caller to pci_enable_msix.  This API has long been deprecated
>> so this series switches it to use pci_alloc_irq_vectors instead.
>>
>> Can you please test it and make sure it goes in before the end of the
>> merge window so that no more users of the old API hit mainline?
>
> Yes the changes works well.
> Acked-by: George Cherian 
>
> for the series.
>>
---end quoted text---


Re: crypto/cavium MSI-X fixups

2017-02-15 Thread George Cherian

Hi Christoph,


On 02/15/2017 12:48 PM, Christoph Hellwig wrote:

Hi George,

your commit "crypto: cavium - Add Support for Octeon-tx CPT Engine"
add a new caller to pci_enable_msix.  This API has long been deprecated
so this series switches it to use pci_alloc_irq_vectors instead.

Can you please test it and make sure it goes in before the end of the
merge window so that no more users of the old API hit mainline?


Yes the changes works well.
Acked-by: George Cherian 

for the series.