From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 15:33:05 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16D7216A41F for ; Mon, 19 Sep 2005 15:33:05 +0000 (GMT) (envelope-from brett@lariat.org) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86C1943D48 for ; Mon, 19 Sep 2005 15:33:04 +0000 (GMT) (envelope-from brett@lariat.org) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id JAA04531; Mon, 19 Sep 2005 09:32:57 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.2.3.4.2.20050919091248.07f767e8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 19 Sep 2005 09:32:36 -0600 To: John-Mark Gurney From: Brett Glass 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 15:33:05 -0000 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