Back in Devember 2003, Yamamoto-san posted a set of patches with
Message-id: <1072758893.063203.8037.nullmailer@yamt.dyndns.org>,
with body

``for someone interested..''

and patches as an attachment.  I recently re-read those patches.  As
several regulars have noted over the past few months, contemporary CPU
cores aren't getting exponentially faster. Instead we should expect
multiple-core CPU chips with increasing numbers of cores.  For those
of us interested in high-speed networking, an SMP-safe networking
stack in one form or another starts looking highly desirable.

Since 2003, Yamamoto-san's suggested change to create i386 locore
ih_realfun/ih_realarg (or a similar version) has already been
committed.  Leaving that aside, I think Yamamoto-san's patch breaks
down into the following main parts:

1.  Creating an interrupt-attach flag which marks suitable drivers as SMP-safe.

2. Machine-depedent changes which allow the kernel to concurrently enter
   such SMP-safe on more than one CPU. So far, only i386 versions were
   offered.
    
3. A locking/SPL hierarchy (or locking order rule), which guarantees the
   kernel remains still deadlock-free.

4. Changes to the network stack's per-protocol input queues,
   making them SMP-safe.

5. Changes to certain network drivers to make them SMP-safe.
   In general, for a driver "foo",  add a simplelock to each device instance.
   then the routines foo_stop(), foo_start(), foo_init() need to be
   separated into two versions: a public version called when the simplelock
   is not held and which aquires the lock; and a private version
   which is called when the  lock is already held.

   I think Yamamoto-san and I agree that following the FreeBSD-5 naming
   scheme is better than Yamamoto-san's original patch for the fxp driver;
   That scheme would use fxp_{stop,start,init{}() for the public entrypoints,
   and fxp_{stop,start_init}_locked() for the internal, lock-held entrypoints.
   (Note that some "SMP-safe" drivers will need to acquire the
   big-lock, e.g., drivers layerd over serial, IPL_TTY devices)


Of those, items #1, #4, and #5 were non-controversial.  As best I
recall, earlier discussion did not reach any consensus on #3; and I
honestly don't recall what, if anything, was decided about
Yamamoto-san's offered i386 version of #2 (i386-specific locore
changes to allow more than 1 CPU to enter the kernel to service
interrupts for SMP-safe devices).

I would very much like to start implementing #4 and #5, based on
Yamamoto-san's patch with the modified aming scheme above.  I think
the FreeBSD-5 experience shows that the above (perhaps with some
extensions) is adequate for SMP-safe (network) drivers.

Starting on the MI portion of the work will, if nothing else, give a
workable platform to investigate and measure different options for the
MD portions and locking/SPL rules.