Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754369AbYHPXVu (ORCPT ); Sat, 16 Aug 2008 19:21:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751878AbYHPXVn (ORCPT ); Sat, 16 Aug 2008 19:21:43 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]:52418 "EHLO wx-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751663AbYHPXVm (ORCPT ); Sat, 16 Aug 2008 19:21:42 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=xMj8BHY07zNnXqER+lGX2vf9yGmWR85zLUzlMjp6Tw3GgzwBoi+uZDA/CwYRUmW+lo 8Kh3d7FhEuDMKSKkN2UFmzJZvCMpwNVnLFQGC9Tkyi663PB/sINn1OPTZXfGJe5bbskr q6EDbEVIMJ6c6Q2tTtvdFDp/Pq1qDozTbPRek= Message-ID: <86802c440808161621m71512c6ao8634034f275c4fec@mail.gmail.com> Date: Sat, 16 Aug 2008 16:21:41 -0700 From: "Yinghai Lu" To: "James Bottomley" Subject: Re: [PATCH] pci: change msi-x vector to 32bit Cc: "Alan Cox" , "H. Peter Anvin" , "Jesse Barnes" , "Ingo Molnar" , "Thomas Gleixner" , "Eric W. Biederman" , "Andrew Morton" , linux-kernel@vger.kernel.org, "Andrew Vasquez" In-Reply-To: <1218928162.3940.62.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808160326.m7G3QR1G012726@terminus.zytor.com> <1218898238.3940.6.camel@localhost.localdomain> <20080816163945.74d487e9@lxorguk.ukuu.org.uk> <1218903209.3940.14.camel@localhost.localdomain> <86802c440808161156rf48f23ai9d77ce3cab36f02a@mail.gmail.com> <1218918341.3940.49.camel@localhost.localdomain> <86802c440808161334q75a7d019ofade0b6cabf3f74d@mail.gmail.com> <1218919547.3940.57.camel@localhost.localdomain> <86802c440808161517y1eaa5a4eo817b8a1bf75945be@mail.gmail.com> <1218928162.3940.62.camel@localhost.localdomain> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2190 Lines: 47 On Sat, Aug 16, 2008 at 4:09 PM, James Bottomley wrote: > On Sat, 2008-08-16 at 15:17 -0700, Yinghai Lu wrote: >> On Sat, Aug 16, 2008 at 1:45 PM, James Bottomley >> wrote: >> >> > What I still don't quite get is the benefit of large IRQ spaces ... >> >> > particularly if you encode things the system doesn't really need to know >> >> > in them. >> >> >> >> then set nr_irqs = nr_cpu_ids * NR_VECTORS)) >> >> and count down for msi/msi-x? >> > >> > No, what I mean is that msis can trip directly to CPUs, so this is an >> > affinity thing (that MSI is directly bound to that CPU now), so in the >> > matrixed way we display this in show_interrupts() with the CPU along the >> > top and the IRQ down the side, it doesn't make sense to me to encode IRQ >> > affinity in the irq number again. So it makes more sense to assign the >> > vectors based on both the irq number and the CPU affinity so that if the >> > PCI MSI for qla is assigned to CPU4 you can reassign it to CPU5 and so >> > on. >> >> msi-x entry index, cpu_vector, irq number... >> >> you want to different cpus have same vector? > > Obviously I'm not communicating very well. Your apparent assumption is > that irq number == vector. What I'm saying is that's not what we've > done for individually vectored CPU interrupts in other architectures. > In those we did (cpu no, irq) == vector. i.e. the affinity and the irq > number identify the vector. For non-numa systems, this is effectively > what you're interested in doing anyway. For numa systems, it just > becomes a sparse matrix. > msix_entry.vector == irq. and cpu have per_cpu(vector_irq), and use that cpu get irq number. when irq migratition, different cpu could use different vector for same irq. or say phys_flat mode, same vector in different cpus could server different irq. it seems x86 (64 bit) and ia64 already did that. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/