Yes. Which is 1024 irq sources/gsis only 1/4 used so it will fit into 256 irqs.
On x86_64 we have removed the confusing and brittle irq compression
code. So to handle that many irqs we would need 1024 irqs.
I expect modern big systems that can only run x86_64 are larger still.
Or we place irq_desc in irq_cfg.
Nah. We lookup whatever it we need in the 256 entry vector_irq table.
I expect we can do the container_of trick beyond that.
If the helper which we should only see on the slow path is a bottleneck
we can easily turn organize irq_desc into a tree structure. Ultimately
I think we want drivers to have a struct irq *irq pointer but we need
to get the arch backend working first.
Certainly there is the potential to simplify things.
The thing is there is no good upper bound of how many irqs we can see
short of of NR_PCI_DEVICES*4096
Yes. Currently for the current worst case it requires 16 cpus.
The biggest I have heard a card using at this point is 256 irqs.
At lot of the goal in those cards is so they can have 2 irqs per cpu.
1 rx irq and 1 tx irq. Allowing them to implement per cpu queues.
Yes. But we can put all the arch specific code in irq_cfg, and put
irq_desc in irq_cfg.
Which is usable, but no where near as nice as not having a fixed upper bound.
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 ]
Eric
--
