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_ms
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 effective
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 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
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_
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, cal
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
> > > > mand
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
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 a
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 probe
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 har
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 gen
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 d
Hello,
On Thu, Sep 26, 2013 at 10:39 AM, Alexander Gordeev 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 in pSeries firmwa
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
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 &
> firmwa
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()
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 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 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
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 w
> 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 i
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 jus
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 u
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 so
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 int
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More major
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
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 pci_get_msi
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 - h
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 th
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 curiosi
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) woul
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
On Mon, Sep 09, 2013 at 11:37:54AM -0400, Tejun Heo wrote:
> Hello,
>
> On Mon, Sep 09, 2013 at 05:20:44PM +0200, Alexander Gordeev wrote:
> > The series is what it seems a direction to take.
>
> It can definitely use better descriptions explaining why this is
> happening but the general directio
Hello,
On Mon, Sep 09, 2013 at 05:20:44PM +0200, Alexander Gordeev wrote:
> The series is what it seems a direction to take.
It can definitely use better descriptions explaining why this is
happening but the general direction seems good to me.
> Looks like we need PPC folks to agree on the quota
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 be nice to quantify that, too.
Hi Bjorn,
The series is what it seem
On Fri, Sep 06, 2013 at 12:06:21PM -0400, Tejun Heo wrote:
> Hello, Bjorn.
>
> On Fri, Sep 06, 2013 at 10:01:38AM -0600, Bjorn Helgaas wrote:
> > Sorry, I haven't jumped in here yet because I saw your discussion and
> > was hoping you guys would figure something out without my help. It
> > will t
On Thu, Sep 5, 2013 at 2:06 PM, Tejun Heo wrote:
> Hello, Alexander.
>
> On Thu, Sep 05, 2013 at 08:54:40PM +0200, Alexander Gordeev wrote:
>> I assume reasons for having this type of interface at the moment of
>> taking design decision about pci_enable_msi_block() still hold true.
>> I do not kno
Hello, Bjorn.
On Fri, Sep 06, 2013 at 10:01:38AM -0600, Bjorn Helgaas wrote:
> Sorry, I haven't jumped in here yet because I saw your discussion and
> was hoping you guys would figure something out without my help. It
> will take me a few hours to look into this and come up with anything
> constr
On Thu, Sep 05, 2013 at 05:40:41PM +0200, Alexander Gordeev wrote:
> On Thu, Sep 05, 2013 at 11:04:42AM -0400, Tejun Heo wrote:
> > The thing is, do we even have cases where arch code returns positive
> > return to indicate possible partial allocation? If not, the whole
> > interface is convoluted
Hello, Alexander.
On Thu, Sep 05, 2013 at 08:54:40PM +0200, Alexander Gordeev wrote:
> I assume reasons for having this type of interface at the moment of
> taking design decision about pci_enable_msi_block() still hold true.
> I do not know what those reasons were, but I think the fact multiple
>
On Thu, Sep 05, 2013 at 11:44:36AM -0400, Tejun Heo wrote:
> Given that multiple MSI is something which isn't too popular / already
> superseded and that the condition is highly unlikely, do we really
> care about possible partial success? This sort of interface is
> unnecessarily complex and acti
Hello,
On Thu, Sep 05, 2013 at 05:40:42PM +0200, Alexander Gordeev wrote:
> On Thu, Sep 05, 2013 at 11:04:42AM -0400, Tejun Heo wrote:
> > The thing is, do we even have cases where arch code returns positive
> > return to indicate possible partial allocation? If not, the whole
> > interface is co
On Thu, Sep 05, 2013 at 11:04:42AM -0400, Tejun Heo wrote:
> The thing is, do we even have cases where arch code returns positive
> return to indicate possible partial allocation? If not, the whole
> interface is convoluted for no good reason and we can just make
> everything return 0 or -errno, w
Hello,
On Thu, Sep 05, 2013 at 05:03:00PM +0200, Alexander Gordeev wrote:
> You mean we could treat positive numbers returned by architecture as
> failures and translate it into negative error codes?
> If so, I would prefer not to do this for two reasons:
> 1. It will not be possible to call pci_e
On Thu, Sep 05, 2013 at 09:09:02AM -0400, Tejun Heo wrote:
> Hello, Alexander.
>
> On Thu, Sep 05, 2013 at 02:52:47PM +0200, Alexander Gordeev wrote:
> One curiosity - with the above factored out, is
> pci_enable_msi_block_part() returning positive number still necessary?
> I followed most of code
Hello, Alexander.
On Thu, Sep 05, 2013 at 02:52:47PM +0200, Alexander Gordeev wrote:
> -int pci_enable_msi_block_part(struct pci_dev *dev,
> - unsigned int nvec, int nvec_mme)
> +int pci_get_msi_cap(struct pci_dev *dev)
> {
> - int status, maxvec;
> + int ret;
>
48 matches
Mail list logo
