In message <20050606221017.GA1761@netbsd.org>Bill Studenmund writes

>I'm now confused a bit.
>
>If we have the ability to mark drivers as SMP-safe on a per-driver case,
>does it matter if we have one-big-lock or per-spl locks? Isn't it the same
>work either way (in terms just of letting a driver be SMP-safe or not)?

Ahhh, but we *dont* have the ability to mark drivers SMP-safe on a
driver-by driver basis -- unless we do one of:

  i) fold all device IPLs into a single level, as in Yamamoto-san's
     patch from Dec 2030, or

 ii) Do lock-per-IPL   (really device and softint IPLs), or

iii) Work down, highest remaining IPL at a time, reworking *all* code
which uses that IPL to instead use explicit locks for synchronization,
then committing the entire rework in one big hit.

I dont think anyone seriously wants option (1), which leaves us with
to option (ii) versus option (iii), or pursuing both concurrently.  I
buy both concurrently, if Yamamoto-san also buys it.

>I thought the biggest win of per-SPL locks was that we could immediately
>move to having multiple CPUs in an SMP system being in interrupt routines
>at the same time.

Yes, per-SPL locks let us do that "immedately" (more accurately, as
soon as we have per-SPL locks). (I suspect my ranking of the benefits
is not quite the same as yours.)






>> The lock-per-IPL enables us make individual drivers SMP-safe, mark
>> them as such. locore/MD code can and will call SMP-safe drivers with*out*
>> acquiring the per-IPL lock.  So I think lock-per-IPL makes it *easier*
>> to move remove locking for the IPL-at-a-time approach: we will already
>> have some (maybe all?) drivers for that IPL which are SMP-safe.
>
>As above, how is that different from not having to aquire the big lock?

I want to start making progress on SMP-safe network drivers now, and
to look seriously at splsoftnet() after that. Yamamoto-san's proposal,
to rework "one entire IPL at a time" gives me _no way_ to do that: I
have to wait until Yamamoto-san and others fix all the higher IPLs.

Unless, say, I start sprinking explicit kernel-lock aqcuire and
release calls all through the kernel at all IPL levels above the ones
I wish to work on.  And that strikes me as significantly more of a
short-term hack and wasted work -- a bigger negative impact -- than
the converse. I think Yamamoto-san said he could live with with
IPL-locks as an interim solution?  

I expect to see SMP-safe network drivers and explicitly-locked
protocol input-queues as arriving within hours after IPL-locking SPLs
are available. I have no estimate for when Yamamoto-san or others will
rework the kernel right down to splsoftnet(), but I expect it will be
much, much longer before we can eliminate _any_ device IPL.

I guess "stop-gap hack" and "waste[d] time" are in the eye of the
beholder...