new mirror site

[Max Laier]

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 at xxxxxxxxxxx
\ /  Max Laier				| ICQ #67774661
 X   http://pf4freebsd.love2party.net/	| mlaier at EFnet
/ \  ASCII Ribbon Campaign		| Against HTML Mail and News
Attachment:
pgp00009.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00009.pgp
Type: application/octet-stream
Size: 187 bytes
Desc: "Description: signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20040716/4266de24/attachment-0020.obj>