| From: | Max Laier <max@xxxxxxxxxxxxxx> |
| Date: | Fri, 16 Jul 2004 20:29:40 +0200 |
On Friday 16 July 2004 19:13, Matthew Dillon wrote: > :The main reason this was held off was because everybody kept saying it > : would interfere with Jeffrey Hsu's work. > : > :Jeff, what's in the pipeline for your network stuff? > : > :I know there's people who would want to use DF, but lack of altq and pf is > :keeping them away. > : > :-- > :Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono > > (I know this is a somewhat old message). I think work could be started > on ALTQ and PF, though it is almost certain that both Jeff and I will > have to mess with it later on when we start to remove the BGL from the > network stack. > > The only 'correct' way to make the packet filters MP safe is to > partition them across cpus, matching the filter entry with the IP demux > hash, and then replicating those filter entries that are not sufficiently > unique to fall into a single demux hash cpu category (for static entries), > or forcing the entries to be handled by a particular cpu (for dynamic > entries). If I may comment on this, it should be relatively easy to partition the dynamic rules (i.e. the state table). Partitionizing the ruleset (esp. with anchors, lables et al) will be much harder. The strong point in pf is it's flexibility and means of "runtime re-configuration" (authpf e.g.), but at the same time that's the thing that makes it very hard to distribute the ruleset evaluation (hence the relatively big lock in the FreeBSD implementation). For a start it might be enough to partition the state table and - if no state exists yet - force the traffic through a single CPU that does the ruleset evaluation and creates state (by IPI to the CPU responsible for the state being created). Of course this is only a first idea ... > It's a headache either way but I don't see it as being a showstopper > any more... it's just something we will have to do after the fact. > > I would rather have PF and ALTQ in the system and then remove > the other filters (e.g. the old IPFW filter), and implement any > lost functionality in PF itself. Then we would only have to deal > with PF and ALTQ for the MP work. Hurray \o/ ... as for ALTQ: it's a driver-local thing which should not cause any problems for Dragonfly in regards to synchronization (you still have spl's, right?) and will just replace the existing ifqueue (which needs the same level of synchronization already). Good luck to anyone taking up the task, there still is a (very outdated) pf patch on my site which you can start from. If you need help, don't hesitate to contact me, though it might take some time for me to answer. One more step towards pf/worlddomination \o/ -- /"\ Best regards, | mlaier@xxxxxxxxxxx \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News
Attachment:
pgp00009.pgp
Description: signature