Re: Network Stack Locking

From: Andre Oppermann (andre_at_freebsd.org)
Date: 05/20/04

  • Next message: Matthew Dillon: "Re: Network Stack Locking" 
    Date: Thu, 20 May 2004 23:32:53 +0200
To: Robert Watson <rwatson@FreeBSD.org>

    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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Matthew Dillon: "Re: Network Stack Locking"