parallelizing ipfw table

[Julian Elischer]

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

would caching help when there are two successive packets of the same flow?
That is not that uncommon, even though larger groupings are less common.