Re: parallelizing ipfw table
From: Gleb Smirnoff (glebius_at_FreeBSD.org)
Date: 11/28/05
- Previous message: John Palmer: "bad udp cksum 26ff!"
- In reply to: Max Laier: "Re: parallelizing ipfw table"
- Next in thread: Andre Oppermann: "Re: parallelizing ipfw table"
- Reply: Andre Oppermann: "Re: parallelizing ipfw table"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 28 Nov 2005 22:17:51 +0300 To: Max Laier <max@love2party.net>
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 _______________________________________________ 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"
- Previous message: John Palmer: "bad udp cksum 26ff!"
- In reply to: Max Laier: "Re: parallelizing ipfw table"
- Next in thread: Andre Oppermann: "Re: parallelizing ipfw table"
- Reply: Andre Oppermann: "Re: parallelizing ipfw table"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
