DragonFly kernel List (threaded) for 2004-07
Re: DragonFly-1.0 RELEASED!
:> 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).
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