ipfw prefix-list support request
rizzo at icir.org
Tue May 18 00:07:11 PDT 2004
On Tue, May 18, 2004 at 05:25:33AM +0200, Max Laier wrote:
> I'll try to describe a bit how it is handled in pf, to give you some more
> hints in case you are going to look at the code ...
> pf uses the existing radix-tree implementation for the tables. This provides
> lookups in O(32) for IPv4 and O(128) for IPv6 which means it's a constant
> time lookup. Unfortunately, the radix code has some locking requirements that
> add overhead but it's sure worth looking at.
well, good luck :) it's not just the locking requirements, it's
the space used for each entry and the very complicated API to
use it that scares me -- basically requiring a lot of extra
work to format arguments.
If anything, a good output from this kind of project would be
a reimplementation of a forwarding table...
> > + remember that ipfw(2) accepts one line at a time -- so there will be
> > times when the configuration is inconsistent e.g. you might have rules
> > pointing to a non-existing list. Make sure the handling of these cases
> > is not terribly expensive.
> I have no clue how to address this, but I find it a rather gross way of
> dealing with a ruleSET ...
well this was for backward compatibility. The way ipfw2/dummynet handle
this is the same way in whihc one should handle pluggable hardware --
invalidate pointers on departures, flag arrivals so that the code
can (lazily) try to update an invalid reference after an arrival.
A generation-id of some kind would make the mechanism very simple.
More information about the freebsd-ipfw