From: Roland Dreier <roland@topspin.com>
To: long <tlnguyen@snoqualmie.dp.intel.com>
Cc: ak@muc.de, akpm@osdl.org, greg@kroah.com, jgarzik@pobox.com,
linux-kernel@vger.kernel.org, tom.l.nguyen@intel.com,
zwane@linuxpower.ca, eli@mellanox.co.il
Subject: Re: [PATCH]2.6.7 MSI-X Update
Date: Wed, 23 Jun 2004 09:50:21 -0700 [thread overview]
Message-ID: <523c4mi5gy.fsf@topspin.com> (raw)
In-Reply-To: <200406222148.i5MLmA4Y001949@snoqualmie.dp.intel.com> (long's message of "Tue, 22 Jun 2004 14:48:10 -0700")
OK, yet another comment on this update :)
Overall I like the idea of separating MSI and MSI-X support and
getting rid of the msi_alloc_vectors()/msi_free_vectors(). However it
seems there is a slight asymmetry in how MSI-X is handled now.
If a driver calls pci_enable_msix() (and the call succeeds), then the
device is immediately put into MSI-X mode -- that is, the enable bit
of its MSI-X capability is set. However, this bit will not be cleared
until the driver calls free_irq() for the last MSI-X vector.
This means that for a driver to clear the MSI-X enable bit, it must
first do request_irq() on all the vectors it was assigned and then
call free_irq(). It seems quite possible to me that a driver may not
use all the MSI-X vectors it is assigned, so device cleanup becomes a
problem. Also, there is no way for the driver to free its unused
MSI-X vectors.
It seems we need a pci_disable_msix() call to match the
pci_enable_msix() call. (And remove the disabling of MSI-X from the
free_irq code path)
I guess there is actually a similar problem with MSI -- if a driver
calls pci_enable_msi(), MSI will not be disabled until the driver does
request_irq/free_irq. This is not quite as serious because a driver
is unlikely not to use the since MSI vector it gets, but it is still a
problem for error cleanup paths. So maybe we need pci_disable_msi()
as well.
What do you think?
Thanks,
Roland
next prev parent reply other threads:[~2004-06-23 17:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-22 21:48 [PATCH]2.6.7 MSI-X Update long
2004-06-22 23:57 ` Roland Dreier
2004-06-23 0:26 ` Jeff Garzik
2004-06-23 1:18 ` Roland Dreier
2004-06-23 3:45 ` Roland Dreier
2004-06-23 16:50 ` Roland Dreier [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-06-22 23:06 Nguyen, Tom L
2004-06-23 16:49 Nguyen, Tom L
2004-06-23 16:58 Nguyen, Tom L
2004-06-23 22:03 Nguyen, Tom L
2004-06-24 1:42 ` Roland Dreier
2004-06-24 6:37 ` Zwane Mwaikambo
2004-06-24 7:27 ` Roland Dreier
2004-06-24 16:29 Nguyen, Tom L
2004-06-26 1:21 long
2004-06-26 0:30 ` [PATCH]2.6.7 " Roland Dreier
2004-06-26 1:38 ` Roland Dreier
2004-06-26 8:27 ` Christoph Hellwig
2004-06-26 17:30 ` Roland Dreier
2004-07-13 22:02 long
2004-07-15 2:14 ` [PATCH]2.6.7 " Roland Dreier
2004-07-18 1:25 ` Roland Dreier
2004-07-15 15:46 Nguyen, Tom L
2004-07-19 15:36 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=523c4mi5gy.fsf@topspin.com \
--to=roland@topspin.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=eli@mellanox.co.il \
--cc=greg@kroah.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tlnguyen@snoqualmie.dp.intel.com \
--cc=tom.l.nguyen@intel.com \
--cc=zwane@linuxpower.ca \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.