From: Roland Dreier <rdreier@cisco.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Shawn Jin <shawnxjin@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: Multiple MSI messages support
Date: Tue, 30 Oct 2007 15:51:08 -0700 [thread overview]
Message-ID: <adaejfci5cz.fsf@cisco.com> (raw)
In-Reply-To: <4727AED2.6010908@garzik.org> (Jeff Garzik's message of "Tue, 30 Oct 2007 18:23:14 -0400")
> > If this is really off-topic here, I apologize first. But I cannot
> > think a better place to ask this particular question.
> > I understand that the current PCI subsystem or linux kernel (x86)
> > supports only one message when MSI is enabled even for devices having
> > multiple MSI messages. But why? Is this a limitation solely due to the
> > OS or due to the x86 APIC?
> > I know the current linux kernel (2.6.23) changed MSI message data
> > format a little bit to support other architectures. But some older
> > version (e.g. 2.6.18) defined a specific format for the MSI msg data
> > in a way that 8 bits contain the irq number and the other 8 bits have
> > the interrupt attributes, which is x86 specific. Why does the msg data
> > need to contain the irq number? Here is my hypothetic explanation. The
> > device writes the MSI msg data to the specified MSI msg address. And
> > APIC uses the irq number in the msg data to generate appropriate
> > interrupt, which of course results in an appropriate ISR invoked. A
> > device having multiple MSI messages typically appends some information
> > of which MSI message to the msg data field. For example, if the system
> > (or OS) configures the MSI msg data as 0x5000, a device having 4 MSI
> > messages could write 0x5000, 0x5001, 0x5002, 0x5003 to differentiate
> > the MSI messages. However this cannot work with the APIC due to the
> > way how APIC asserts interrupts as I described above (if my
> > understanding is correct).
> > Hence my answer to the question is this is due to the x86 APIC. For
> > other architectures such as powerpc this is probably not a problem
> > since the interrupt controller is different. Am I correct?
> IMO it's more like there has never been enough need for anybody to
> look into it, I bet...
Actually the original poster's explanation is pretty accurate. MSI
imposes a restriction on how a device generates multiple messages,
since there is only one message data register and the rest of the
messages must be based on that in a simple way. And the format of
"Intel-style" APIC MSI messages does not match up with the way the PCI
spec generates multiple messages.
In fact at least IBM pSeries boxes seem to be able to use MSI to
generate multiple interrupts from the same device -- BenH can probably
give details.
Multiple interrupt messages are supported by Linux via MSI-X (which
allows each message to have completely different data).
> The way drivers are written, you are typically must touch a few key
> hardware registers _anyway_, so the multiple messages in practice are
> not much more useful than the simple fact that your MSI irq handler
> function was called (with all that indicates and implies).
For high-performance devices this is not really true. The InfiniBand
mthca driver can use MSI to get a single interrupt, or MSI-X to get
different interrupts for different types of events. MSI-X allows the
read of the "interrupt cause register" to be avoided, and this ends up
making a measurable performance difference for the fast path.
Also, obviously, having multiple interrupts means you can bind
different interrupts to different CPUs, which will become very
important if/when things like multi-queue NICs are supported.
- R.
next prev parent reply other threads:[~2007-10-30 22:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-30 21:13 Multiple MSI messages support Shawn Jin
2007-10-30 22:23 ` Jeff Garzik
2007-10-30 22:51 ` Roland Dreier [this message]
2007-10-30 23:02 ` David Miller
2007-10-31 1:34 ` Shawn Jin
2007-10-31 4:00 ` Jeff Garzik
2007-10-31 5:05 ` Shawn Jin
2007-10-31 5:17 ` Roland Dreier
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=adaejfci5cz.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shawnxjin@gmail.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;
as well as URLs for NNTP newsgroup(s).