Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 May 2004 00:07:06 -0700
From:      Luigi Rizzo <rizzo@icir.org>
To:        Max Laier <max@love2party.net>
Cc:        freebsd-ipfw@freebsd.org
Subject:   Re: ipfw prefix-list support request
Message-ID:  <20040518000706.A96220@xorpc.icir.org>
In-Reply-To: <200405180525.36273.max@love2party.net>; from max@love2party.net on Tue, May 18, 2004 at 05:25:33AM %2B0200
References:  <40A8C12D.5040906@email.dp.ua> <20040517151050.B63591@xorpc.icir.org> <200405180525.36273.max@love2party.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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 ...

good, thanks.

> 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.

cheers
luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040518000706.A96220>