public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspin.com>
To: Greg KH <gregkh@suse.de>
Cc: tom.l.nguyen@intel.com, linux-pci@atrey.karlin.mff.cuni.cz,
	linux-kernel@vger.kernel.org, davem@davemloft.net
Subject: Re: pci_enable_msi() for everyone?
Date: Fri, 03 Jun 2005 16:36:17 -0700	[thread overview]
Message-ID: <524qcft3m6.fsf@topspin.com> (raw)
In-Reply-To: <20050603224551.GA10014@kroah.com> (Greg KH's message of "Fri, 3 Jun 2005 15:45:51 -0700")

    Greg> In talking with a few people about the MSI kernel code, they
    Greg> asked why we can't just do the pci_enable_msi() call for
    Greg> every pci device in the system (at somewhere like
    Greg> pci_enable_device() time or so).  That would let all drivers
    Greg> and devices get the MSI functionality without changing their
    Greg> code, and probably make the api a whole lot simpler.

    Greg> Now I know the e1000 driver would have to specifically
    Greg> disable MSI for some of their broken versions, and possibly
    Greg> some other drivers might need this, but the downside seems
    Greg> quite small.

This was discussed the first time around when MSI patches were first
posted, and the consensus then was that it should be an "opt in"
system for drivers.  However, perhaps things has matured enough now
with PCI Express catching on, etc.

I think the number of devices truly compliant with the MSI spec is
quite tiny.  Probably just about every driver for a device that
actually has an MSI capability in its PCI header will need code to
work around some breakage, or will just end up disabling MSI entirely
because it never works.  Also I don't know how many PCI host bridges
implement MSI correctly.  For example we have a quirk for AMD 8131,
but who knows how many other chipsets are broken (and some bugs may be
much more subtle than the way the AMD 8131 breaks, which is to never
deliver interrupts).

Also, there needs to be a way for drivers to ask for multiple MSI-X
vectors.  For example the mthca InfiniBand driver gets a nice
performance boost by using separate interrupts for different types of
events.  I'm also planning on adding support for having one completion
interrupt per CPU, to help SMP scalability.

With all that said this might be a good idea, as long as there's a way
for drivers to enable MSI-X cleanly and a way for people to disable
the whole thing (eg a boot option).

 - R.

  parent reply	other threads:[~2005-06-04 15:02 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-03 22:45 pci_enable_msi() for everyone? Greg KH
2005-06-03 23:16 ` Jeff Garzik
2005-06-04  0:01   ` Benjamin Herrenschmidt
2005-06-04  0:08     ` Jeff Garzik
2005-06-04  0:16       ` Benjamin Herrenschmidt
2005-06-04  0:34         ` Jeff Garzik
2005-06-04  6:51   ` Greg KH
2005-06-03 23:36 ` Roland Dreier [this message]
2005-06-06 22:58   ` Greg KH
2005-06-07  0:23     ` Roland Dreier
2005-06-07  5:19       ` Greg KH
2005-06-04  1:31 ` Grant Grundler
2005-06-04  6:48   ` Greg KH
2005-06-04  7:05     ` Grant Grundler
2005-06-04  7:18       ` Greg KH
2005-06-04  7:23         ` Dave Jones
2005-06-04 14:58           ` Roland Dreier
2005-06-06 23:01           ` Greg KH
2005-06-07  0:26             ` Roland Dreier
2005-06-07  5:22               ` Greg KH
2005-06-07  5:46                 ` Adam Belay
2005-06-07 17:43                   ` Luben Tuikov
2005-06-05 22:00         ` Benjamin Herrenschmidt
2005-06-06 23:00           ` Greg KH
2005-06-06 23:56             ` Benjamin Herrenschmidt
2005-06-05 19:46 ` David S. Miller
2005-06-06 22:55   ` Greg KH
2005-06-06 22:59     ` David S. Miller
2005-06-06 23:09       ` Greg KH
2005-06-06 23:08     ` Jeff Garzik
2005-06-06 23:10       ` David S. Miller
2005-06-06 23:13       ` Greg KH
2005-06-06 23:53         ` Jeff Garzik
2005-06-06 23:56           ` Greg KH
2005-06-06 23:58           ` David S. Miller
2005-06-07  4:24       ` Grant Grundler
2005-06-07  0:18     ` Roland Dreier
2005-06-07  5:21       ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2005-06-07 22:33 Nguyen, Tom L

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=524qcft3m6.fsf@topspin.com \
    --to=roland@topspin.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=tom.l.nguyen@intel.com \
    /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