DragonFly-1.0 RELEASED!

[Matthew Dillon]

:>     Even if we do bring in PF and stick with it, we will still need
:>     to make significant number of changes to make it properly work
:>     with our networking model.
:
:That means porting PF is impossible ?
:I really don't know how PF works (internal) and why it's incompatible with the 
:current network model but is possible to start a port or is it better to write 
:a new packet filter ?
:What I want from PF is AltQ than the firewall (I currently use ipf/ipnat).
:
:Regards,
:
:F.Julien

    I wouldn't say impossible.  The issue with PF, as with all the 
    packet filter engines, is that they are not designed for MP systems.
    This doesn't mean we can't run them, but it does mean we either have
    to run them as a degenerate single-threaded case (which is how we handle
    packet fragments at the moment, by the way), or we have to make the 
    filter(s) MP safe - probably through table replication across available
    cpus, at least for the static entries.  TCP flows are actually easier to
    deal with since those can be distributed across cpus using the standard
    distribution hash that the TCP protocol stack uses.  Other dynamic
    entities might be more difficult.

    Generally speaking it's far easier for us to adapt these inherently
    uni-processor filter engines to DragonFly then it is for the FreeBSD
    developers to adapt them to FreeBSD-5, because we can always funnel
    the non-distributable portions of the filter to a single serialized
    thread.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>