Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Sun, 16 Mar 2025 22:00:41 +0000
Organization: Rocksolid Light
Message-ID: <b5c8db99d23a4f894242658e21797e99@www.novabbs.org>
References: <vqto79$335c6$1@dont-email.me> <YyFAP.729659$eNx6.235106@fx14.iad> <6731f278e3a9eb70d34250f43b7f15f2@www.novabbs.org> <AUHAP.61125$Xq5f.14972@fx38.iad> <748c0cc0ba18704b4678fd553193573e@www.novabbs.org> <2YJAP.403746$zz8b.238811@fx09.iad> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="488088"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$DvGVjKT4J16Rn1rtso9OLeot6Yoc3A94HiT8ux81UtS5JsszOzfLO
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71

On Sun, 16 Mar 2025 21:35:29 +0000, Robert Finch wrote:

> On 2025-03-15 6:28 p.m., MitchAlsup1 wrote:
>> On Sat, 15 Mar 2025 20:46:41 +0000, Robert Finch wrote:
>>
>>> On 2025-03-15 1:46 p.m., MitchAlsup1 wrote:
>>>> On Sat, 15 Mar 2025 2:10:48 +0000, Robert Finch wrote:
>> ------------
>>> The SoC system is limited to 64 CPU cores by the use of a 6-bit core
>>> number. So, a 64-bit vector containing which cores to send the interrupt
>>> to could be used. A find-first-one responding could be used to mask
>>> things so that only one CPU sees the interrupt.
>>
>> 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.

I can't talk about this for another week or so.

> To identify the CPU pool, with a max of 63 CPU per interrupt controller,

Terminology:: My 66000 has 1 interrupt controller (per chip) that can
process MSI-X messages for an unbounded number of interrupt tables and
an unbounded number of cores. Each interrupt table is associated with a
Guest OS (VM) or HyprrVisor (VMM) or ...

The only limitation is the size of the interrupt aperture--

OH, and BTW, I use the word aperture rather than range as the range
may be sparse with unbounded number of holes of unbounded length in
the range {begin..end}. And the service port only services things
in the aperture not in necessarily the range.

> the pool could be represented directly as a 64-bit word in the interrupt
> vector table. I have been thinking of using a 256-bit vector entry
> instead of 128-bits. I allocated 96-bit for an instruction / address
> field.

I think you are drifting towards "affinity" (and a flat version of that
itself). Not a wrong way to go, but fraught with peril.

You might be better off heading into a vector of 64-bit containers
which specify participation in one or more affinity groups per core.