public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
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

  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