Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 May 2004 23:32:53 +0200
From:      Andre Oppermann <andre@freebsd.org>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        arch@FreeBSD.org
Subject:   Re: Network Stack Locking
Message-ID:  <40AD2405.DC13B45C@freebsd.org>
References:  <Pine.NEB.3.96L.1040520162957.90528H-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.  One of my main dislikings
of the current 'net' and 'netinet' code is it's obfuscation and really
overloaded functions.  Even though I'm very fluent in the IPv4 network
code it is still hurting my eye and brain when looking through certain
files...  So I've started to clean up large parts of it.  The very
first thing is to get ipfw out of ip_input/ip_output which I have early
patches (see last status report).  In that patch are two more things.
One is to make ip_reass() a real function taking a fragemented packet
instead of being a half-way stub only capable of being called from
ip_input.  The second thing is to move all ip options related functions
(which are quite many/large and seldomly used) to their own .c/.h file.
With that alone both ip_input/ip_output shrink by approx. 1/3 in size
and get way more readable and understandable.

Well, the only thing I really want to say is that correctly working
code is always a great base to optimize from.  I think this is one
of the big lessions I've learned through my relatively young kernel
programming career and from the VM work of John Dyson (for the younger
among us, he and David Greenman did the orginal implementation of the
unified VM we have.  John lost himself in micro-optimizations where
he somewhat lost the ability to see the forest because of all the
trees in the way.  In the end he had to give it up).

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

-- 
Andre



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40AD2405.DC13B45C>