Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Mon, 17 Mar 2025 11:23:24 -0400
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <vr9epd$cqbc$1@dont-email.me>
References: <vqto79$335c6$1@dont-email.me>
 <53b8227eba214e0340cad309241af7b5@www.novabbs.org>
 <3pXAP.584096$FVcd.26370@fx10.iad>
 <795b541375e3e0f53e2c76a55ffe3f20@www.novabbs.org>
 <vNZAP.37553$D_V4.18229@fx39.iad>
 <aceeec2839b8824d52f0cbe709af51e1@www.novabbs.org>
 <eM_AP.81303$8rz3.7843@fx37.iad> <vr2nj9$2goqe$1@dont-email.me>
 <f2cb846242dbfcef1efa59b92763a965@www.novabbs.org>
 <vr4ovm$9fl5$1@dont-email.me>
 <1681197d3c1af131d6b8cae884f7c9ca@www.novabbs.org>
 <vr7g76$2jnqm$1@dont-email.me> <8BVBP.816276$eNx6.247046@fx14.iad>
 <20250317161132.00004dd9@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 17 Mar 2025 16:23:26 +0100 (CET)
Injection-Info: dont-email.me; posting-host="001673f4264b4066073135678ae93834";
	logging-data="420204"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18/vhNKKXX95ud9anBrcEHbRBomPt+WqiQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ALpZX21z0HdjIYfG3pog3EOalwE=
Content-Language: en-US
In-Reply-To: <20250317161132.00004dd9@yahoo.com>
Bytes: 3784

On 2025-03-17 10:11 a.m., Michael S wrote:
> On Mon, 17 Mar 2025 13:38:12 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
> 
>> Robert Finch <robfi680@gmail.com> writes:
>>>   
>>    <please trim posts>
>>
>>>>
>>>> Consider that you have a pool of 4 cores setup to receive
>>>> interrupts. That those 4 cores are running at differing priorities
>>>> and the interrupt is at a still different priority. You want the
>>>> core operating at the lowest
>>>> priority (with the right software stack) to accept the interrupt
>>>> !!
>>>
>>> Okay, I wrote a naive hardware filter for this which should work
>>> okay for small numbers of CPUs but does not scale up very well.
>>> What happens if there is no core ready? Place the IRQ back into the
>>> queue (regenerate the IRQ as an IRQ miss IRQ)? Or just wait for an
>>> available core. I do not like the idea of waiting as it could stall
>>> the system.
>>
>> Use a fifo to hold up to N pending IRQ. Define a signal that asserts
>> when the fifo is non-empty.  The CPU can mask the signal to prevent
>> interruption, when the signal is unmasked the CPU pops the
>> first IRQ from the FIFO.   Or use a bitmap in flops or SRAM
>> (prioritization happensin the logic that asserts the fact
>> hat an interrupt is pending to the CPU).
>>
>> Choose whether you want a FIFO/bitmap per target CPU, or global
>> pending data with the logic to select highest priority pending
>> IRQ when the CPU signals that interrups are not masked.
> 
> The problem Robert is talking about arises when there are many
> interrupt source and many target CPUs.
> The required routing/prioritization/acknowledgment logic (at least a
> naive logic I am having in mind) would be either non-scalable or
> relatively complicated. Process of selection for the second case will
> take multiple cycles (I am thinking about ring).
> 
> 
Yeah, that was an issue.

My naive filter occupied only about 50 LUTs for eight CPU cores which is 
probably okay timing wise. But it jumped up to about 1500 LUTs for 63 
cores. I think it is O^2 logic.
My thought was to try using something like the bit arrays for an age matrix.
Race logic is to be avoided. It cannot be processed in an FPGA.