Network Stack Locking

[Peter Jeremy]

On Thu, 2004-May-20 23:32:53 +0200, Andre Oppermann wrote:
>Robert Watson wrote:
>...
>> Note that there are some serious issues with the current locking changes:
>...
>> 
>
>I vote for the approach to get in as much as possible from the moment
>on it is known to work *correctly* (not neccessarily perfectly optimal/
>optimized).  Having something correct is an ideal base to start for
>optimizing.  There I'm ready to jump in and go ahead to make things
>better by re-arraning or re-writing them.

Keep in mind that the best improvements in performance are achieved by
using a better algorithm - macro-optimisation rather than micro-
optimisation.  We currently have a network stack that works correctly
and should be careful about committing WIP code that may be heading in
the wrong direction.

>Progress happens incrementally.  Put in Green's kqueue locking, have
>that working correctly and make it perfect in a second step.

I don't believe this is the correct approach at this time.  Brian's
code removes functionality that people have stated that they _do_ use.
In theory, John-Mark's approach offers better performance without the
loss of functionality.  Before implementing Brian's code, the Project
needs to decide which direction it should move in.
-- 
Peter Jeremy