Date: Mon, 19 Sep 2005 09:32:36 -0600 From: Brett Glass <brett@lariat.org> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Luigi Rizzo <rizzo@icir.org>, net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW Message-ID: <6.2.3.4.2.20050919091248.07f767e8@localhost> In-Reply-To: <20050919094012.GB821@funkthat.com> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919094012.GB821@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 03:40 AM 9/19/2005, John-Mark Gurney wrote: >What's awkward about: >#define PIPE_FOO 1 >#define PIPE_BAR 2 > >add pipe PIPE_FOO config bw 64kbit/sec >/* ... etc ... */ I've done that, and unfortunately it does not solve the problem I'm describing. The awkward and inefficient part comes when you have nontrivial criteria for passing the packets into the pipe. Due to the limited semantics of IPFW's "language," you must manually generate inverses of rules. This is tricky and error-prone and replaces each single rule with multiple rules, creating lots of overhead. And when you surround the rules with other rules (both manually and automatically generated), you can run into BASIC-like numbering problems. In the end, even with a preprocessor you wind up generating a rule set that's huge, complex, inefficient, spaghetti-like, and very difficult to read and maintain. To put it another way: this isn't the sort of situation that lends itself to the use of a preprocessor because the preprocessor can't solve the underlying problem: the constraints of the language it is generating. If the goal is to keep IPFW's language straightforward, simple, and readable (important for firewalls, since the results of messing up can be a catatonic machine and angry users), it's best to give it the semantics it needs to do what's necessary. The ability to negate an entire IPFW rule rather than just the individual conditions in it (that is, do a "short circuit NAND" of all the conditions in it) would be a big help, not only in this situation but in others. But the "resume" option would be even more efficient in many cases. --Brett Glass
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.3.4.2.20050919091248.07f767e8>