I have made small patch to cache results per "table" and this caching gives me about 92% hit ratio with a lot of session.
----- Original Message ----- From: "Ruslan Ermilov" <[EMAIL PROTECTED]> To: "Gleb Smirnoff" <[EMAIL PROTECTED]> Cc: "Vsevolod Lobko" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, November 27, 2005 9:45 PM Subject: Re: parallelizing ipfw table > 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 > [EMAIL PROTECTED] > FreeBSD committer > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
