Re: Network Stack Locking

From: Robert Watson (rwatson_at_freebsd.org)
Date: 05/21/04

  • Next message: Robert Watson: "Re: Network Stack Locking" 
    Date: Fri, 21 May 2004 12:19:53 -0400 (EDT)
To: Andre Oppermann <andre@freebsd.org>

    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

    _______________________________________________
    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: Robert Watson: "Re: Network Stack Locking"

    Relevant Pages