Date: Wed, 9 Dec 2009 19:38:21 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: ipfw@freebsd.org Subject: RFC: new ipfw options Message-ID: <20091209183821.GA40814@onelab2.iet.unipi.it>
next in thread | raw e-mail | index | archive | help
Hi,
I would like to discuss some new features that I am going to add to ipfw.
1. A new option "lookup <search-key> T[,V]" where
search-key ::= {src-ip|dst-ip|src-port|dst-port|proto|jail|...}
This extends the existing '{dst-ip|src-ip} table(T[,V])' options,
and allows a lookup of other packet fields such as ports, protocols,
uid, jails (I need this one).
In terms of additional code the impact is rather small both
in userland and kernel.
2. A fast dispatch table for skipto
As you may know, "skipto tablearg" is rather inefficient
because there are no direct pointers to the jump target,
so the O(log N) the table lookup is killed by the subsequent
O(N) instruction lookup.
The plan here is to add an optional skipto table
that contains <rule_nr,rule_id,rule_ptr> so that computed
skipto also take between O(log N) and O(1) depending on the
implementation.
a) a sysctl can enable or disable the table (off by default);
b) the initial implementation would be a trivial array
with 64k entries containing rule_id and rule_ptr (rule_nr
is implicit). It consumes 512-768k of memory (the reason
why I'd default to off) but is fast and reliable.
As an alternative, perhaps at a later time, I might
put in a version that uses a smaller array, say 256 or 4k
entries, at a price of 16..256 search loops worst case
(this is still 3 orders of magnitude than what we have now)
3. a hash version of 'table's
Right now ipfw tables are implented as routing tables, which is
great if you have to lookup a longest matching prefix, but a
bit overkill if you care only for ports or jail ids, and
totally uninteresting if you want to lookup flow ids,
or generic sequence of bytes. My plan here is to reuse the
ipfw hash tables to make them available for 'ipfw table ...'
commands. To avoid code and syntax bloat, I'd use the number
0..TABLE_MAX-1 for the existing prefix tables, and
TABLE_MAX..2TABLE_MAX-1 for the new hash tables.
comments welcome
cheers
luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091209183821.GA40814>