From: Michael Ellerman <michael@ellerman.id.au>
To: Alexander Gordeev <agordeev@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Tejun Heo <tj@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>, Joerg Roedel <joro@8bytes.org>,
Jan Beulich <JBeulich@suse.com>,
Bjorn Helgaas <bhelgaas@google.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
Date: Tue, 1 Oct 2013 17:51:33 +1000 [thread overview]
Message-ID: <20131001075133.GJ17966@concordia> (raw)
In-Reply-To: <20130918094759.GA2353@dhcp-26-207.brq.redhat.com>
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")?
>
> > 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 ;)
>
> 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).
OK, but we have the source to the drivers, we could just fix them.
We could even add:
pci_enable_msix_i_am_stupid()
Which swallows the positive return and just gives back -ve/0.
> 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.
Sure, that's fine if those drivers do that, it's up to the drivers after
all.
> Another quite common pattern is a call to pci_enable_msix() to figure out
> the number of MSI-Xs available and a repeated call of pci_enable_msix()
> to enable those MSI-Xs, this time.
Also fine, though as the documentation suggests a loop is the best
construct rather than two explicit calls.
> The recommended practice would be:
>
> /*
> * 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;
>
> Thoughts?
We could probably make that work.
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 the limitations. The ultimate way to check if
firmware will give us enough MSIs is to try and allocate them. But we
can't do that from pci_get_msix_limit() because the driver is not asking
us to enable MSIs, just query them.
You'll also need to add another arch hook, for the quota check, and
we'll have to add it to our per-platform indirection as well.
All a lot of bother for no real gain IMHO.
cheers
next prev parent reply other threads:[~2013-10-01 7:51 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-05 12:51 [PATCH v2 0/6] AHCI: Conserve interrupts with pci_enable_msi_block_part() interface Alexander Gordeev
2013-09-05 12:52 ` [PATCH v2 1/6] PCI/MSI: Introduce " Alexander Gordeev
2013-09-05 12:52 ` [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface Alexander Gordeev
2013-09-05 13:09 ` Tejun Heo
2013-09-05 15:03 ` Alexander Gordeev
2013-09-05 15:04 ` Tejun Heo
2013-09-05 15:40 ` Alexander Gordeev
2013-09-05 15:44 ` Tejun Heo
2013-09-05 18:54 ` Alexander Gordeev
2013-09-05 20:06 ` Tejun Heo
2013-09-06 16:01 ` Bjorn Helgaas
2013-09-06 16:06 ` Tejun Heo
2013-09-06 23:32 ` Bjorn Helgaas
2013-09-09 15:20 ` Alexander Gordeev
2013-09-09 15:22 ` [PATCH 1/9] PCI/MSI/PPC: Fix wrong RTAS error code reporting Alexander Gordeev
2013-09-09 15:22 ` [PATCH 2/9] PCI/MSI/PPC: Make return values only 0/-errno when MSIs allocated Alexander Gordeev
2013-09-09 15:24 ` [PATCH 3/9] PCI/MSI/x86: " Alexander Gordeev
2013-09-09 15:24 ` [PATCH 4/9] PCI/MSI/MIPS: " Alexander Gordeev
2013-09-09 15:25 ` [PATCH 2/9] PCI/MSI/PPC: Make return values only 0/-errno when MSIs allocated[PATCH 5/9] PCI/MSI/s390: " Alexander Gordeev
2013-09-09 15:38 ` scrap this one Alexander Gordeev
2013-09-09 15:26 ` [PATCH 5/9] PCI/MSI/s390: Make return values only 0/-errno when MSIs allocated Alexander Gordeev
2013-09-10 12:42 ` Sergei Shtylyov
2013-09-10 13:09 ` Alexander Gordeev
2013-09-09 15:27 ` [PATCH 6/9] PCI/MSI/s390: Remove superfluous check of MSI type Alexander Gordeev
2013-09-09 15:28 ` [PATCH 7/9] PCI/MSI/s390: Make return values only 0/-errno when MSIs allocated Alexander Gordeev
2013-09-09 15:29 ` [PATCH 8/9] PCI/MSI: Fix return value when populate_msi_sysfs() failed Alexander Gordeev
2013-09-09 15:29 ` [PATCH 9/9] PCI/MSI: Make return values only 0/-errno when MSIs allocated Alexander Gordeev
2013-09-09 15:37 ` [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface Tejun Heo
2013-09-09 15:45 ` Alexander Gordeev
2013-09-16 10:22 ` Alexander Gordeev
2013-09-17 14:30 ` Michael Ellerman
2013-09-18 9:48 ` Alexander Gordeev
2013-09-18 14:22 ` Tejun Heo
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 [this message]
2013-10-01 10:35 ` Alexander Gordeev
2013-10-02 2:43 ` Michael Ellerman
2013-10-02 7:10 ` Alexander Gordeev
2013-09-06 13:17 ` Alexander Gordeev
2013-09-05 12:53 ` [PATCH v2 3/6] MSI/x86: Support pci_enable_msi_block_part() interface Alexander Gordeev
2013-09-05 12:53 ` [PATCH v2 4/6] AHCI: Conserve interrupts with " Alexander Gordeev
2013-09-05 13:10 ` Tejun Heo
2013-09-05 15:23 ` Alexander Gordeev
2013-09-05 12:54 ` [PATCH v2 5/6] AHCI: Check MRSM bit when multiple MSIs enabled Alexander Gordeev
2013-09-05 13:11 ` Tejun Heo
2013-09-05 15:25 ` Alexander Gordeev
2013-09-05 14:32 ` Sergei Shtylyov
2013-09-05 12:54 ` [PATCH v2 6/6] PCI/MSI: Get rid of pci_enable_msi_block_auto() interface 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=20131001075133.GJ17966@concordia \
--to=michael@ellerman.id.au \
--cc=JBeulich@suse.com \
--cc=agordeev@redhat.com \
--cc=benh@kernel.crashing.org \
--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=tj@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).