Date: Fri, 21 May 2004 12:19:53 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: arch@freebsd.org Subject: Re: Network Stack Locking Message-ID: <Pine.NEB.3.96L.1040521121549.4759B-100000@fledge.watson.org> In-Reply-To: <40AD2405.DC13B45C@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 May 2004, 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. 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. I agree generally with all of the improvements you have proposed -- cleaning up the ip_input() and ip_output() paths is imperative. Likewise attempting to reduce the incestuousness of the stack and its various components, normalize utility functions such as reassembly, etc. > 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). Agreed. My goal in picking up the pieces from various people working on this has been get to the "decent first pass" so that we can finally understand how all the pieces come together. There should be a number of fairly easy optimizations we can look into once we're able to measure accurately the impact of changes in the locking strategy. The trick is getting that decent first pass -- we're close, but not quite there. The good news is that the dual-mode model allows us to merge locking on components without that locking necessarily being 100% complete. I anticipate a non-trivial window in which whether you can run Giant-free depends on whether you're using more obscure stack components, for example. I hope it is not long enough that we have to improve the mechanism for the dual-mode (i.e., have the kernel select running with Giant based on the code compiled in, etc). Right now it's a simple loader tunable. Anyhow, my hope is to have a substantial amount of time to work on cleaning up this weekend so that I can update the patch sets. I also need to integrate in changes from rik to make userspace compile with the modified kernel, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040521121549.4759B-100000>