Date: Sat, 22 May 2004 07:32:08 +1000 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Andre Oppermann <andre@freebsd.org> Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: Network Stack Locking Message-ID: <20040521213208.GA87546@cirb503493.alcatel.com.au> In-Reply-To: <40AD2405.DC13B45C@freebsd.org> References: <Pine.NEB.3.96L.1040520162957.90528H-100000@fledge.watson.org> <40AD2405.DC13B45C@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040521213208.GA87546>