Date: Sun, 27 Nov 2005 22:00:01 +0200 From: "Mihail Balikov" <misho@interbgc.com> To: <net@freebsd.org> Subject: Re: parallelizing ipfw table Message-ID: <002801c5f38d$2885c1c0$0cddf0d5@misho> References: <20051127005943.GR25711@cell.sick.ru><20051127135529.GF25711@cell.sick.ru> <20051127194545.GA76200@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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" <ru@FreeBSD.org> To: "Gleb Smirnoff" <glebius@FreeBSD.org> Cc: "Vsevolod Lobko" <seva@ip.net.ua>; <rwatson@FreeBSD.org>; <net@FreeBSD.org> 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 > ru@FreeBSD.org > FreeBSD committer > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002801c5f38d$2885c1c0$0cddf0d5>