From: Tejun Heo <tj@kernel.org>
To: Alexander Gordeev <agordeev@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>, "x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
Jan Beulich <JBeulich@suse.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linuxppc-dev@lists.ozlabs.org, Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
Date: Wed, 18 Sep 2013 09:22:31 -0500 [thread overview]
Message-ID: <20130918142231.GA21650@mtj.dyndns.org> (raw)
In-Reply-To: <20130918094759.GA2353@dhcp-26-207.brq.redhat.com>
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
> > will get most/all of the MSIs and other devices miss out.
>
> Out of curiosity - how pSeries has had done it without quotas before
> 448e2ca ("powerpc/pseries: Implement a quota system for MSIs")?
Hmmm... do we need to treat this any differently? If the platform
can't allocate full range of requested MSIs, just failing should be
enough regardless of why such allocation can't be met, no?
> > Anyway I don't see what problem you're trying to solve? I agree the
> > -ve/0/+ve return value pattern is ugly, but it's hardly the end of the
> > world.
>
> Well, the interface recently has been re-classified from "ugly" to
> "unnecessarily complex and actively harmful" in Tejun's words ;)
LOL. :)
> Indeed, I checked most of the drivers and it is incredible how people
> are creative in misusing the interface: from innocent pci_disable_msix()
> calls when if pci_enable_msix() failed to assuming MSI-Xs were enabled
> if pci_enable_msix() returned a positive value (apparently untested).
>
> 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. People have to
actively resist to avoid doing silly stuff which is a lot to ask.
> /*
> * Retrieving 'nvec' by means other than pci_msix_table_size()
> */
>
> rc = pci_get_msix_limit(pdev);
> if (rc < 0)
> return rc;
>
> /*
> * nvec = min(rc, nvec);
> */
>
> for (i = 0; i < nvec; i++)
> msix_entry[i].entry = i;
>
> rc = pci_enable_msix(pdev, msix_entry, nvec);
> if (rc)
> return rc;
I really think what we should do is
* Determine the number of MSIs the controller wants. Don't worry
about quotas or limits or anything. Just determine the number
necessary to enable enhanced interrupt handling.
* Try allocating that number of MSIs. If it fails, then just revert
to single interrupt mode. It's not the end of the world and mostly
guaranteed to work. Let's please not even try to do partial
multiple interrupts. I really don't think it's worth the risk or
complexity.
Thanks.
--
tejun
next prev parent reply other threads:[~2013-09-18 14:22 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130905150259.GA30984@dhcp-26-207.brq.redhat.com>
[not found] ` <20130905150442.GA24148@htj.dyndns.org>
[not found] ` <20130905154041.GD30984@dhcp-26-207.brq.redhat.com>
[not found] ` <20130905154436.GC24148@htj.dyndns.org>
[not found] ` <20130905185440.GA13175@dhcp-26-207.brq.redhat.com>
[not found] ` <20130905200608.GA3846@htj.dyndns.org>
[not found] ` <CAErSpo4TU2geqzY3AYsL08KimBqtfwa4iUoFHgcFt0zMTBJkHw@mail.gmail.com>
[not found] ` <20130906160621.GF22763@mtj.dyndns.org>
[not found] ` <20130906233205.GF12956@google.com>
[not found] ` <20130909152044.GA24962@dhcp-26-207.brq.redhat.com>
2013-09-16 10:22 ` [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface Alexander Gordeev
2013-09-17 14:30 ` Michael Ellerman
2013-09-18 9:48 ` Alexander Gordeev
2013-09-18 14:22 ` Tejun Heo [this message]
2013-09-18 16:50 ` Alexander Gordeev
2013-09-20 8:24 ` Alexander Gordeev
2013-09-20 12:27 ` Tejun Heo
2013-09-25 18:02 ` Bjorn Helgaas
2013-09-25 20:58 ` Alexander Gordeev
2013-09-25 21:00 ` Tejun Heo
2013-09-26 7:46 ` Alexander Gordeev
2013-09-26 8:58 ` David Laight
2013-09-26 10:45 ` Alexander Gordeev
2013-09-26 11:34 ` David Laight
2013-09-26 12:13 ` Alexander Gordeev
2013-09-26 13:11 ` Tejun Heo
2013-09-26 14:39 ` Alexander Gordeev
2013-09-26 14:42 ` Tejun Heo
2013-10-01 7:19 ` Michael Ellerman
2013-09-20 12:26 ` Tejun Heo
2013-10-01 7:26 ` Michael Ellerman
2013-10-01 7:35 ` Michael Ellerman
2013-10-01 11:55 ` Tejun Heo
2013-10-02 2:33 ` Michael Ellerman
2013-10-02 3:23 ` Tejun Heo
2013-09-26 12:32 ` Mark Lord
2013-09-26 13:03 ` Alexander Gordeev
2013-10-02 2:46 ` Mark Lord
2013-10-02 7:26 ` Alexander Gordeev
2013-12-18 18:26 ` Bjorn Helgaas
2013-10-01 7:51 ` Michael Ellerman
2013-10-01 10:35 ` Alexander Gordeev
2013-10-02 2:43 ` Michael Ellerman
2013-10-02 7:10 ` Alexander Gordeev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130918142231.GA21650@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=JBeulich@suse.com \
--cc=agordeev@redhat.com \
--cc=bhelgaas@google.com \
--cc=joro@8bytes.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).