parallelizing ipfw table

Ruslan Ermilov ru at FreeBSD.org
Sun Nov 27 19:46:15 GMT 2005


On Sun, Nov 27, 2005 at 04:55:29PM +0300, Gleb Smirnoff wrote:
> On Sun, Nov 27, 2005 at 03:59:43AM +0300, Gleb Smirnoff wrote:
> T> A patch displaying the idea is attached. Not tested yet, read
> T> below. The patch moves the tables array into the ip_fw_chain
> T> structure. This is not necessary now, but in future we can
> T> have multiple independent chains in ipfw, that's why I try
> T> to avoid usage of &layer3_chain in the functions that are
> T> deeper in the call graph. I try to supply chain pointer
> T> from the caller.
> T> 
> T> The only problem is the caching in table lookup. This "hack"
> T> makes the lookup function modify the table structure. We need
> T> to remove caching to make the lookup_table() function fully
> T> lockless and reenterable at the same time. The attached patch
> T> doesn't removes caching, since it only displays the original
> T> idea.
> 
> Okay, I have made a working patch, that is now undergoing testing
> on SMP. I have axed all the caching from ipfw tables, to make
> lookup_table() lockless and reenterable. This axing simplified
> things much. I believe that the caching gives a benefit only
> when we serve a small number of clients, and is only additional
> workload when we are routing hundreds and thousands of simultaneous
> IP flows.
> 
> The patch attached. I'm going to put it into production testing as
> soon as I can reboot the prod box.
> 
Nope, I need this caching.  It's for looking up the same table
several times in a row but with various values.  For example,
we use ipfw tables to route the traffic to the correct dummynet
pipe, where value is the bandwidth, and this caching helps a lot.


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


More information about the freebsd-net mailing list