[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131219134244.GA32238@dhcp-26-207.brq.redhat.com>
Date: Thu, 19 Dec 2013 14:42:45 +0100
From: Alexander Gordeev <agordeev@...hat.com>
To: Bjorn Helgaas <bhelgaas@...gle.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Michael Ellerman <michael@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Tejun Heo <tj@...nel.org>,
Ben Hutchings <bhutchings@...arflare.com>,
David Laight <David.Laight@...lab.com>,
Mark Lord <kernel@...rt.ca>, "H. Peter Anvin" <hpa@...or.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH v4 9/9] PCI/MSI: Introduce pci_auto_enable_msi*() family
helpers
On Wed, Dec 18, 2013 at 11:58:47AM -0700, Bjorn Helgaas wrote:
> If rc == 13 and the device can only use 8, the extra 5 would be
> ignored and wasted.
>
> If the waste is unacceptable, the driver can try this:
>
> rc = pci_enable_msix_range(dev->pdev, dev->irqs, 16, 16);
> if (rc < 0) {
> rc = pci_enable_msix_range(dev->pdev, dev->irqs, 8, 8);
> if (rc < 0) {
> rc = pci_enable_msix_range(dev->pdev, dev->irqs, 4, 4);
> ...
> }
I have troubles with this fallback logic. On each failed step we get an
error and we do not know if this is indeed an error or an indication of
insufficient MSI resources. Even -ENOSPC would not tell much, since it
could be thrown from a lower level.
By contrast, with the tri-state return value we can distinguish and bail
out on errors right away.
So the above is bit ungraceful for me. Combined with a possible waste in
logs (if we're hitting the same error) it is quite enough for me to keep
current the interfaces, at least for a time being.
> if (rc < 0) { /* error, couldn't allocate *any* interrupts */
> else { /* rc interrupts allocated (1, 2, 4, 8, or 16) */ }
>
> Bjorn
--
Regards,
Alexander Gordeev
agordeev@...hat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists