Date: Mon, 28 Nov 2005 22:17:51 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Max Laier <max@love2party.net> Cc: freebsd-net@FreeBSD.org, rwatson@FreeBSD.org, Ruslan Ermilov <ru@FreeBSD.org>, Vsevolod Lobko <seva@ip.net.ua> Subject: Re: parallelizing ipfw table Message-ID: <20051128191751.GZ25711@cell.sick.ru> In-Reply-To: <200511281805.11952.max@love2party.net> References: <20051127005943.GR25711@cell.sick.ru> <20051128062732.GA58778@ip.net.ua> <20051128161934.GY25711@cell.sick.ru> <200511281805.11952.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 28, 2005 at 06:04:50PM +0100, Max Laier wrote: M> On Monday 28 November 2005 17:19, Gleb Smirnoff wrote: M> > The number 65535 is some magic number, which means "take argument from M> > table". I will make ipfw display some word instead of 65535, for example M> > "tablearg". So, the rule will be looking like: M> > M> > pipe tablearg ip from any to table(1) M> M> This is not a good idea - IMHO. The problem is twofold: First, it adds a M> special handling for a special case and is not a general sollution to the M> problem (i.e. what if I want to use altq instead?). Second, it adds M> complexity to the already painfully complex ipfw-grammar. In my opinion we M> need a cleanup here first. This will also work for netgraph/ngtee and divert/tee (already in done in my patch). Since ALTQ uses not numbers but strings to identify its entities, adding ALTQ support here is harder, but possible. We just need alter the ipfw_table_ent() to hold strings. I will do it someday, if my current proposal won't die in a bikeshed. The ipfw-grammar diff is almost zero length - just print magic number as a string. In general I don't accept the policy: stop adding features until you do a cleanup. Following this policy we might end with a subsystem that has stalled and no one is developing it. But if someone is adding features, he usually also does some cleanup inlined. For example here I'm moving the dummynet pipe/queue to hashes, and this can be called a cleanup - at least one XXX less. I accept this kind of objection: "please stop adding features, since I am now working on the cleanup in this area", but I think this is not the case. M> I remember that we had an extensive discussion about this around M> FreeBSD-SA-05:13.ipfw - the bottom line seems to be: either parallel or M> cacheing. Stack storage should work as well. The cacheing is a good idea when one table is looked up several times for one packet. The above proposal eliminates need for such rulesets. And thus we can work towards parallelizm. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051128191751.GZ25711>