Re: [PATCH] pci: change msi-x vector to 32bit

From: James Bottomley
Date: Sat Aug 16 2008 - 16:49:12 EST


On Sat, 2008-08-16 at 13:34 -0700, Yinghai Lu wrote:
> On Sat, Aug 16, 2008 at 1:25 PM, James Bottomley
> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> >> but msix current cached irq number, and it only use 16bit to store
> >> unsigned int irq., and later cards will call request_irq with
> >> truncated irq_number...card will fallback to MSI or INTa
> >
> > OK, sorry, I get that there's a bug in the msix_entry ... if it's going
> > to assign an irq to it, it should at least be the same type as irq.
>
> good. for 2.6.27?

Well, given that 2.6.27 uses a compact irq space, probably not ...
unless there's actually something in 2.6.27 that trips it?

> >
> > 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.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/