Date: Sun, 27 Nov 2005 12:34:47 -0800 From: Julian Elischer <julian@elischer.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: rwatson@freebsd.org, Vsevolod Lobko <seva@ip.net.ua>, net@freebsd.org Subject: Re: parallelizing ipfw table Message-ID: <438A1867.1030009@elischer.org> In-Reply-To: <20051127135529.GF25711@cell.sick.ru> References: <20051127005943.GR25711@cell.sick.ru> <20051127135529.GF25711@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?438A1867.1030009>