On Thu, Sep 26, 2013 at 08:32:53AM -0400, Mark Lord wrote:
On 13-09-18 05:48 AM, Alexander Gordeev wrote:
The last pattern makes most of sense to me and could be updated with a more
clear sequence - a call to (bit modified) pci_msix_table_size() followed
by a call to pci_enable_msix(). I
On Wed, Oct 02, 2013 at 12:43:24PM +1000, Michael Ellerman wrote:
On Tue, Oct 01, 2013 at 12:35:27PM +0200, Alexander Gordeev wrote:
On Tue, Oct 01, 2013 at 05:51:33PM +1000, Michael Ellerman wrote:
The disadvantage is that any restriction imposed on us above the quota
can only be
On Tue, Oct 01, 2013 at 10:46:32PM -0400, Mark Lord wrote:
The last pattern makes most of sense to me and could be updated with a
more
clear sequence - a call to (bit modified) pci_msix_table_size() followed
by a call to pci_enable_msix(). I think this pattern can effectively
supersede
On Thu, Sep 26, 2013 at 04:39:02PM +0200, Alexander Gordeev wrote:
On Thu, Sep 26, 2013 at 09:11:47AM -0400, Tejun Heo wrote:
Because otherwise we will re-introduce a problem described by Michael:
We have a small number of MSIs available, limited by hardware
firmware, if we don't impose
On Fri, Sep 20, 2013 at 07:26:03AM -0500, Tejun Heo wrote:
Hello,
On Wed, Sep 18, 2013 at 06:50:45PM +0200, Alexander Gordeev wrote:
Actually, I do not see much contradiction with what I proposed. The
key words here determine the number of MSIs the controller wants.
In general case it
On Wed, Sep 18, 2013 at 09:22:31AM -0500, Tejun Heo wrote:
Hello,
On Wed, Sep 18, 2013 at 11:48:00AM +0200, Alexander Gordeev wrote:
On Wed, Sep 18, 2013 at 12:30:23AM +1000, Michael Ellerman wrote:
How about no?
We have a small number of MSIs available, limited by hardware
On Wed, Sep 18, 2013 at 11:48:00AM +0200, Alexander Gordeev wrote:
On Wed, Sep 18, 2013 at 12:30:23AM +1000, Michael Ellerman wrote:
How about no?
We have a small number of MSIs available, limited by hardware
firmware, if we don't impose a quota then the first device that probes
will
On Tue, Oct 01, 2013 at 05:51:33PM +1000, Michael Ellerman wrote:
The disadvantage is that any restriction imposed on us above the quota
can only be reported as an error from pci_enable_msix().
The quota code, called from pci_get_msix_limit(), can only do so much to
interogate firmware about
Hello,
On Tue, Oct 01, 2013 at 05:35:48PM +1000, Michael Ellerman wrote:
Roughly third of the drivers just do not care and bail out once
pci_enable_msix() has not succeeded. Not sure how many of these are
mandated by the hardware.
Yeah, I mean, this type of interface is a trap.
On Tue, Oct 01, 2013 at 07:55:03AM -0400, Tejun Heo wrote:
Hello,
On Tue, Oct 01, 2013 at 05:35:48PM +1000, Michael Ellerman wrote:
Roughly third of the drivers just do not care and bail out once
pci_enable_msix() has not succeeded. Not sure how many of these are
mandated by the
On Tue, Oct 01, 2013 at 12:35:27PM +0200, Alexander Gordeev wrote:
On Tue, Oct 01, 2013 at 05:51:33PM +1000, Michael Ellerman wrote:
The disadvantage is that any restriction imposed on us above the quota
can only be reported as an error from pci_enable_msix().
The quota code, called from
On 13-09-26 09:03 AM, Alexander Gordeev wrote:
On Thu, Sep 26, 2013 at 08:32:53AM -0400, Mark Lord wrote:
On 13-09-18 05:48 AM, Alexander Gordeev wrote:
The last pattern makes most of sense to me and could be updated with a more
clear sequence - a call to (bit modified) pci_msix_table_size()
On Wed, Oct 02, 2013 at 12:33:38PM +1000, Michael Ellerman wrote:
It is an interface which forces the driver writers to write
complicated fallback code which won't usually be excercised.
It does not force anyone to do anything. That's just bull.
Yeah, sure, we don't have shitty code in
On Wed, Sep 25, 2013 at 05:00:16PM -0400, Tejun Heo wrote:
Hello,
On Wed, Sep 25, 2013 at 10:58:05PM +0200, Alexander Gordeev wrote:
Unfortunately, pSeries is a shows-topper here :( It seems we have to
introduce pci_get_msi{,x}_limit() interfaces to honour the quota
thing. I just hope
Subject: Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
On Wed, Sep 25, 2013 at 05:00:16PM -0400, Tejun Heo wrote:
Hello,
On Wed, Sep 25, 2013 at 10:58:05PM +0200, Alexander Gordeev wrote:
Unfortunately, pSeries is a shows-topper here :( It seems we have
On Thu, Sep 26, 2013 at 09:58:53AM +0100, David Laight wrote:
Would it be possible to do some kind of 2-stage allocation.
In the first pass the driver would pass a minimum and desired
number of MSI-X interrupts, but not actually be given any.
Repeated calls to msi_enable_msi/msix() is what we
On Thu, Sep 26, 2013 at 09:58:53AM +0100, David Laight wrote:
Would it be possible to do some kind of 2-stage allocation.
In the first pass the driver would pass a minimum and desired
number of MSI-X interrupts, but not actually be given any.
Repeated calls to msi_enable_msi/msix() is
On Thu, Sep 26, 2013 at 12:34:36PM +0100, David Laight wrote:
I was thinking that the first call would be done during driver probe
(assuming such a time exists) so that the subsystem could determine
how many interrupts all the drivers would like, so it can then
hand out a smaller number to
On 13-09-18 05:48 AM, Alexander Gordeev wrote:
The last pattern makes most of sense to me and could be updated with a more
clear sequence - a call to (bit modified) pci_msix_table_size() followed
by a call to pci_enable_msix(). I think this pattern can effectively
supersede the currently
On Thu, Sep 26, 2013 at 08:32:53AM -0400, Mark Lord wrote:
On 13-09-18 05:48 AM, Alexander Gordeev wrote:
The last pattern makes most of sense to me and could be updated with a more
clear sequence - a call to (bit modified) pci_msix_table_size() followed
by a call to pci_enable_msix(). I
Hello,
On Thu, Sep 26, 2013 at 09:46:46AM +0200, Alexander Gordeev wrote:
Can you please go into a bit of detail on that? Why does it matter?
Because otherwise we will re-introduce a problem described by Michael:
We have a small number of MSIs available, limited by hardware
firmware, if
On Thu, Sep 26, 2013 at 09:11:47AM -0400, Tejun Heo wrote:
Because otherwise we will re-introduce a problem described by Michael:
We have a small number of MSIs available, limited by hardware
firmware, if we don't impose a quota then the first device that probes
will get most/all of the
Hello,
On Thu, Sep 26, 2013 at 10:39 AM, Alexander Gordeev agord...@redhat.com wrote:
I can imagine a scenario where the first device probes in, requests its
Well, we can imagine a lot of thing but usually have to draw the line somewhere.
optimal number, acquires that number and exhausts MSIs
On Fri, Sep 20, 2013 at 07:27:36AM -0500, Tejun Heo wrote:
On Fri, Sep 20, 2013 at 10:24:59AM +0200, Alexander Gordeev wrote:
* Make pci_enable_msix() return 0/-errno
My choice would be this one.
I agree; it sounds like you've identified several bugs related to the
current confusing
On Wed, Sep 25, 2013 at 12:02:20PM -0600, Bjorn Helgaas wrote:
On Fri, Sep 20, 2013 at 07:27:36AM -0500, Tejun Heo wrote:
On Fri, Sep 20, 2013 at 10:24:59AM +0200, Alexander Gordeev wrote:
* Make pci_enable_msix() return 0/-errno
My choice would be this one.
I agree; it sounds like
Hello,
On Wed, Sep 25, 2013 at 10:58:05PM +0200, Alexander Gordeev wrote:
Unfortunately, pSeries is a shows-topper here :( It seems we have to
introduce pci_get_msi{,x}_limit() interfaces to honour the quota
thing. I just hope the hardware set for pSeries is limited and we
won't need to use
Michael et al.
The identifiable options sounded so far were:
* Do not change anything
* Make pci_enable_msix() return 0/-errno
* Make pci_enable_msix() return 0/-errno and introduce arch_get_msix_limit()/
arch_get_msi_limit()
* Make pci_enable_msix() return 0/-errno and introduce
Hello,
On Wed, Sep 18, 2013 at 06:50:45PM +0200, Alexander Gordeev wrote:
Actually, I do not see much contradiction with what I proposed. The
key words here determine the number of MSIs the controller wants.
In general case it is not what pci_msix_table_size() returns (or at
least we should
On Fri, Sep 20, 2013 at 10:24:59AM +0200, Alexander Gordeev wrote:
* Make pci_enable_msix() return 0/-errno
My choice would be this one.
Thanks.
--
tejun
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Wed, Sep 18, 2013 at 12:30:23AM +1000, Michael Ellerman wrote:
How about no?
We have a small number of MSIs available, limited by hardware
firmware, if we don't impose a quota then the first device that probes
will get most/all of the MSIs and other devices miss out.
Out of curiosity -
Hello,
On Wed, Sep 18, 2013 at 11:48:00AM +0200, Alexander Gordeev wrote:
On Wed, Sep 18, 2013 at 12:30:23AM +1000, Michael Ellerman wrote:
How about no?
We have a small number of MSIs available, limited by hardware
firmware, if we don't impose a quota then the first device that probes
On Wed, Sep 18, 2013 at 09:22:31AM -0500, Tejun Heo wrote:
We have a small number of MSIs available, limited by hardware
firmware, if we don't impose a quota then the first device that probes
will get most/all of the MSIs and other devices miss out.
Out of curiosity - how pSeries
On Mon, Sep 16, 2013 at 12:22:11PM +0200, Alexander Gordeev wrote:
On Mon, Sep 09, 2013 at 05:20:44PM +0200, Alexander Gordeev wrote:
On Fri, Sep 06, 2013 at 05:32:05PM -0600, Bjorn Helgaas wrote:
I propose that you rework it that way, and at least find out what
(if anything) would break
On Mon, Sep 09, 2013 at 05:20:44PM +0200, Alexander Gordeev wrote:
On Fri, Sep 06, 2013 at 05:32:05PM -0600, Bjorn Helgaas wrote:
I propose that you rework it that way, and at least find out what
(if anything) would break if we do that. Or maybe we just give up
some optimization; it would
34 matches
Mail list logo
