On 04/30/2018 02:53 AM, Zhang, Lei wrote:

Hi Marc

thanks for your opinions.

quoted

How many is many? Are they PCI? Or something else?

quoted

As it is, this patch will break Multi-MSI and some other platforms that
do require a higher allocation granule.

Depending on whether you're using PCI or some other bus, we can probably
come up with a solution that works for everyone. But I need more
information on this.

Actually it is our original interconnect device not on PCI but on our original bus.
This device has many sub devices around one thousand, and each sub device requires only a few LPIs.

As I explained in point1, each Device ID can still allocate enough LPIs more than IRQS_PER_CHUNK by increasing chunks.
So I couldn't understand why this patch will break Multi-MSI.

By the way, 32 seems a good default value for IRQS_PER_CHUNK.
So, I want to write another patch to make IRQ_PER_CHUNK a variable which can be changed by kernel parameter.
What do you think of this idea?

If you intend your devices to be supported by server distributions,  
instead of embedded kernels, having IRQ_PER_CHUNK as a kernel parameter  
is not a good idea. The server distributions are going to compile, test,  
and support a single kernel for all server systems, and are not going to  
have a special kernel to support one vendor's systems that has a  
different IRQ_PER_CHUNK parameter.

So even if you wrote that patch and it was accepted into the kernel, the  
server distribution kernels are still going to set IRQ_PER_CHUNK to 32.

Marc's suggestion of implementing a glue layer, and then changing the  
glue layer interface to pass the allocation requirements up to this  
driver is the best solution that can be supported for server products.

--Mark Langsdorf