> Eduardo E. Horvath <eeh@one-o.com> wrote
> 
> > I'm planning on switching the sparc64 port over to a new interface:
> >
> > void send_softint __P((int cpu, int level, struct intrhand *handler));
> >
> > cpu is the CPU number, -1 is this CPU, and -2 is any CPU.
> > level is the numerical interrupt level, 1..15.
> > handler is a ponter to the intrhand structure to be queued.  If
> >        it's NULL then an interrupt is generated but no particular
> >        vector is set and the dispatcher must poll all interrupt
> >        handlers at that level until one claims the interrupt.
> >
> > This should reduce the overhead in interrupt dispatch since the
> > dispatcher will not have to traverse a linked list and poll each of
> > the different interrupt handlers to see which one the interrupt
> > belongs to.
> 
> This is rather interesting in respect to having MI SMP framework
> common across various NetBSD ports.
> 
> I have been thinking around how IPI (inter-processor interrupt)
> notification can be organized, specifically for NetBSD/luna88k and MP
> NetBSD/arc.  Isn't it better to continue the discussion in tech-smp? 

O.K.  Let's discuss this.  (I added tech-kern to the list.)

The purpose for this original proposal was to provide a single,
unified interface drivers can use to send softints.  The current
situation is that each port has its own interface, sometimes several
different interfaces, for sending softints.  This binds any drivers
that need to send some sort of softint to a particular machine
architecture.

I had a particular need to pass a pointer to the intrhand structure
since that's what gets queued up on the sparc64 port.  I just threw in
the CPU stuff for future expandability.  On some architectures it may
make sense to schedule a softint on a different CPU while this one
continues handling something else.

Nor for the SMP portion of the discussion.

With regard to crosscalls: I expect the mechanism for delivering a
crosscall wold be different on different architectures.  Presuming one
CPU really could interrupt another one, softint mechanism described
above would be suitable for issuing certain heavy-weight crosscalls,
or distributing interrupt load across a set of CPUs.

The advantage of using this interface would be to allow one CPU to
request another CPU to execute arbitrary code.

One issue with this interface is the selection of target CPUs.  If the
target is the currently running CPU, this is relatively simple.  If
the target is all other CPUs, for things like TLB shootdowns, it's
only slighhtly more complex.  However, when you want to do something
fancy, such as schedule it on a CPU that's at a lower IPL than the
softint you're scheduling the selection algorithms get tricky.

However, I expect to use a different mechanism for dispatching most
softcalls, since the overhead to enter a `C' language context is
considerable, and things like TLB shootdowns and cache flushes can be
done more efficiently in assembly.  In fact the TLB shootdown code
itself is smaller than the code to call a `C' language interrupt
handler.

=========================================================================
Eduardo Horvath				eeh@netbsd.org
	"I need to find a pithy new quote." -- me