From: Jesse Barnes <jbarnes@engr.sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: PCI Express
Date: Wed, 09 Mar 2005 01:29:13 +0000 [thread overview]
Message-ID: <200503081729.15336.jbarnes@engr.sgi.com> (raw)
In-Reply-To: <4228F250.7C5E2E3C@sgi.com>
On Tuesday, March 08, 2005 4:13 pm, Colin Ngam wrote:
> That's what I will find out before deciding to use it. It is not used for
> IPIs on our platform, probably for very good reasons.
Yep, because IPIs generated from the local block to a distant processor won't
work otherwise (afaik).
> If we can and the
> address is the same than it is a no brainer.
>
> > targetted there should also work. The problem for us is if a processor
> > tries to IPI a processor on a different node with the processor interrupt
> > block, which I don't think MSIs will try to do.
>
> Perhaps you can elaborate. I am not sure what you are trying to say here.
The SHub manual is a little vague here, but my understanding is that in order
to send remote IPIs we need to use the SHub, whereas local IPIs (i.e.
processor to itself or to the other CPU on the same FSB) will work fine.
An MSI should behave like a processor sending an IPI to itself since its
address can be targeted at the processor's interrupt block and set to
generate a local interrupt. Is that right, Tom & Grant?
If this won't work for us, no biggie, we just have to abstract things a little
more. We could make the MSI into a platform specific cookie that we can
store a SHub/PIC/TIO address in and other platforms can use to target the
processor interrupt block. Hopefully we won't have to do that though, since
it would require a few more changes.
Jesse
next prev parent reply other threads:[~2005-03-09 1:29 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-04 23:42 PCI Express Colin Ngam
2005-03-07 16:48 ` Grant Grundler
2005-03-07 16:50 ` Matthew Wilcox
2005-03-07 17:02 ` Mark Maule
2005-03-07 17:21 ` Matthew Wilcox
2005-03-07 20:40 ` Colin Ngam
2005-03-07 23:03 ` Nguyen, Tom L
2005-03-07 23:11 ` Jesse Barnes
2005-03-07 23:31 ` Grant Grundler
2005-03-07 23:32 ` Nguyen, Tom L
2005-03-07 23:36 ` Grant Grundler
2005-03-07 23:40 ` Jesse Barnes
2005-03-07 23:50 ` Grant Grundler
2005-03-08 4:40 ` Colin Ngam
2005-03-08 16:45 ` Jesse Barnes
2005-03-08 19:29 ` Nguyen, Tom L
2005-03-08 23:48 ` Colin Ngam
2005-03-09 0:02 ` Jesse Barnes
2005-03-09 0:13 ` Colin Ngam
2005-03-09 1:29 ` Colin Ngam
2005-03-09 1:29 ` Jesse Barnes [this message]
2005-03-09 1:35 ` Colin Ngam
2005-03-09 3:04 ` Grant Grundler
2005-03-09 15:45 ` Colin Ngam
2005-03-09 16:35 ` Nguyen, Tom L
2005-03-09 17:33 ` Grant Grundler
2005-03-09 17:42 ` Colin Ngam
2005-03-09 17:56 ` Grant Grundler
2005-03-09 18:12 ` Colin Ngam
2005-03-09 18:48 ` Grant Grundler
2005-03-09 19:43 ` Nguyen, Tom L
2005-03-09 21:44 ` Colin Ngam
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=200503081729.15336.jbarnes@engr.sgi.com \
--to=jbarnes@engr.sgi.com \
--cc=linux-ia64@vger.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