public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	Mike Travis <travis@sgi.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/16] dyn_array and nr_irqs support v2
Date: Fri, 01 Aug 2008 19:03:18 -0700	[thread overview]
Message-ID: <4893C066.60401@zytor.com> (raw)
In-Reply-To: <86802c440808011901w2aa40b25u45f5686b262cc2aa@mail.gmail.com>

Yinghai Lu wrote:
>>> cpu is going to check that vectors in addition to vectors in IDT?
>> No. The destination cpu and destination vector number are encoded in
>> the MSI message.  Each MSI-X source ``vector'' has a different MSI message.
>>
>> So on my wish list is to stably encode the MSI interurrpt numbers.  And
>> using a sparse irq address space I can.  As it only takes 28 bits to hold
>> the complete bus + device + function + msi source [ 0-4095 ]
> 
> how about ioapic interrupt numbers...? they should stay with same
> numbering with gsi?
> 
> and how about pci segments : that will need another 4 bits for AMD
> systems..aka 16 segments..
> 
> you will run out of 32bits...
> 

I also see little value in stably encoding IRQ numbers using 
geographical identifiers.  It seems that the only case where you care 
that an interrupt number is stable is when it is *not* tied to a 
geographically addressed entity, so why does it matter?

	-hpa

  reply	other threads:[~2008-08-02  2:05 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-01  9:37 [PATCH 00/16] dyn_array and nr_irqs support v2 Yinghai Lu
2008-08-01  9:37 ` [PATCH 01/16] x86: 64bit support more than 256 irq Yinghai Lu
2008-08-01  9:37   ` [PATCH 02/16] x86: introduce nr_irqs for 64bit v3 Yinghai Lu
2008-08-01  9:37     ` [PATCH 03/16] add dyn_array support Yinghai Lu
2008-08-01  9:37       ` [PATCH 04/16] make irq_timer_state to use dyn_array Yinghai Lu
2008-08-01  9:37         ` [PATCH 05/16] make irq2_iommu " Yinghai Lu
2008-08-01  9:37           ` [PATCH 06/16] make irq_desc " Yinghai Lu
2008-08-01  9:37             ` [PATCH 07/16] x86: make 64bit support dyn_array Yinghai Lu
2008-08-01  9:37               ` [PATCH 08/16] serial: change remove NR_IRQS in 8250.c v2 Yinghai Lu
2008-08-01  9:37                 ` [PATCH 09/16] add per_cpu_dyn_array support Yinghai Lu
2008-08-01  9:37                   ` [PATCH 10/16] irq: make irqs in kernel stat use per_cpu_dyn_array Yinghai Lu
2008-08-01  9:37                     ` [PATCH 11/16] x86 remove irq_vectors_limit.h Yinghai Lu
2008-08-01  9:37                       ` [PATCH 12/16] x86: make 32bit use dyn_array Yinghai Lu
2008-08-01  9:37                         ` [PATCH 13/16] add per_cpu_dyn_array for arch percpu support Yinghai Lu
2008-08-01  9:37                           ` [PATCH 14/16] x86: get mp_irqs from madt Yinghai Lu
2008-08-01  9:37                             ` [PATCH 15/16] x86: make 32bit more like with io_apic/dyn_array to 64 bit Yinghai Lu
2008-08-01  9:37                               ` [PATCH 16/16] x86: alloc dyn_array all alltogether Yinghai Lu
2008-08-01 20:46 ` [PATCH 00/16] dyn_array and nr_irqs support v2 Eric W. Biederman
2008-08-01 21:30   ` Yinghai Lu
2008-08-01 21:57     ` Yinghai Lu
2008-08-01 22:45       ` Eric W. Biederman
2008-08-01 22:10     ` Yinghai Lu
2008-08-01 22:38     ` Eric W. Biederman
2008-08-02  1:09       ` Yinghai Lu
2008-08-02  1:36         ` H. Peter Anvin
2008-08-02  1:41         ` Eric W. Biederman
2008-08-02  2:01           ` Yinghai Lu
2008-08-02  2:03             ` H. Peter Anvin [this message]
2008-08-02  2:39               ` Eric W. Biederman
2008-08-02  3:28                 ` H. Peter Anvin
2008-08-02  4:42                   ` Eric W. Biederman
2008-08-02 15:41                     ` H. Peter Anvin
2008-08-02 20:20                       ` Eric W. Biederman
2008-08-04 12:57           ` Mike Travis
2008-08-05  2:38             ` H. Peter Anvin
2008-08-05  3:40               ` Eric W. Biederman
2008-08-05  3:48                 ` H. Peter Anvin
2008-08-01 21:47   ` Mike Travis
2008-08-02  2:58   ` Yinghai Lu

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=4893C066.60401@zytor.com \
    --to=hpa@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=travis@sgi.com \
    --cc=yhlu.kernel@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