From: Colin Ngam <cngam@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: PCI Express
Date: Wed, 09 Mar 2005 01:35:04 +0000 [thread overview]
Message-ID: <422E52C8.691CF868@sgi.com> (raw)
In-Reply-To: <4228F250.7C5E2E3C@sgi.com>
Jesse Barnes wrote:
> 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.
May be the way we go. Needs more perusal of the MSI code.
Thanks.
colin
>
>
> Jesse
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2005-03-09 1:35 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
2005-03-09 1:35 ` Colin Ngam [this message]
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=422E52C8.691CF868@sgi.com \
--to=cngam@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