DragonFly BSD
DragonFly bugs List (threaded) for 2010-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

New IP header cleanup branch available for testing, stage 2 work in progress

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 26 May 2010 16:37:48 -0700 (PDT)

    My leaf repo now has a branch called 'iphdr'.  Here's the git remote

    [remote "dillon"]
	    url = git://leaf.dragonflybsd.org/~dillon/dragonfly.git
	    fetch = +refs/heads/*:refs/remotes/dillon/*

    git fetch dillon
    git branch iphdr dillon/iphdr
    git checkout iphdr

    I have done basic testing with ipfw, pf, ipv4 fragmentation,
    ipv4 TCP, a little bridging, if_tap, and ipv4 UDP.

    Tons of other things haven't been tested yet.  ipv6, bpf filters,
    carp, more extensive ipfw2 and pf, and so forth.  Donn't bother
    with IPSEC, it has other issues which will have to be solved in
    the next stage.

    Only do testing if you have some experience with the interfaces
    in question.

    This branch contains the network byte ordering and adjustment fixes for
    ip_len, ip_off, and a large chunk of the protosw cleanup.  I am going
    to leave the branch alone except for bug fixes.


    I am now starting work on another branch that will contain a rewrite
    of the whole ether/ip demux and dispatch mechanic.  All protocols
    will become per-cpu and there will be just one protocol support
    thread for each cpu.  NETISRs will go away and be replaced with a
    more direct netmsg queueing operation.  The toeplitz hash will be
    integrated into the demux mechanic (probably integrated with
    ip_lengthcheck()), so the cpu switch will occur even before a
    protocol is handed the packet.  Fast-forwarding will still occur
    in the demux and be able to bypass netmsg queueing.

    Hopefully when all is said and done the combination of the stage 1
    fixes now available and this stage 2 work will give us a huge degree
    of flexibility with regards to managing packet mbufs, including an
    ability to trivially requeue them (something IPSEC and other tunnel
    implementations need to be able to do).

    This second stage will probably take a week at least.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]