parallelizing ipfw table

[Ruslan Ermilov]

On Sun, Nov 27, 2005 at 10:59:14PM +0300, Gleb Smirnoff wrote:
>   Ruslan,
> 
> On Sun, Nov 27, 2005 at 09:45:45PM +0200, Ruslan Ermilov wrote:
> R> Nope, I need this caching.  It's for looking up the same table
> R> several times in a row but with various values.  For example,
> R> we use ipfw tables to route the traffic to the correct dummynet
> R> pipe, where value is the bandwidth, and this caching helps a lot.
> 
> Have you benchmarked that this caching is important? On a router
> that serves a lot of parallel traffic flows the caching is not
> a benefit, but additional processing. I think we should optimize
> the code for more loaded environments, since we don't care about
> CPU consumption in a less loaded setup - whether it is 0.1% or 0.11%.
> 
I'm talking about the following case: the same packet is
processed by a firewall ruleset that has N rules that
look up the same ipfw table but with different "values",
to select a correct dummynet pipe.

> In general such kind of caching in network code is an old fashion,
> that causes a problems when we attempt to make code more
> parallelizable. We alreade removed rtcache in ip_output.c rev. 1.201
> and we will soon remove route caching in gif(4), because it causes
> problems on SMP.
> 
> Can you try my patch? Since it reduces the total number of mutex
> operations it should be a win on UP, too.
> 
We're currently based on 4.x.  You can try it yourself: create
a table with 10000 entries and with value 13.  Then write a
ruleset with 13 rules that look up this table so that the last
rule looks it up with value 13, and do a benchmark.  Let me
know what are results with and without caching.


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer