From owner-freebsd-ipfw@FreeBSD.ORG Wed Dec 9 18:30:00 2009 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16BE4106566B for ; Wed, 9 Dec 2009 18:30:00 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id D431F8FC14 for ; Wed, 9 Dec 2009 18:29:59 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B8660730DA; Wed, 9 Dec 2009 19:38:21 +0100 (CET) Date: Wed, 9 Dec 2009 19:38:21 +0100 From: Luigi Rizzo To: ipfw@freebsd.org Message-ID: <20091209183821.GA40814@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RFC: new ipfw options X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 18:30:00 -0000 Hi, I would like to discuss some new features that I am going to add to ipfw. 1. A new option "lookup T[,V]" where search-key ::= {src-ip|dst-ip|src-port|dst-port|proto|jail|...} This extends the existing '{dst-ip|src-ip} table(T[,V])' options, and allows a lookup of other packet fields such as ports, protocols, uid, jails (I need this one). In terms of additional code the impact is rather small both in userland and kernel. 2. A fast dispatch table for skipto As you may know, "skipto tablearg" is rather inefficient because there are no direct pointers to the jump target, so the O(log N) the table lookup is killed by the subsequent O(N) instruction lookup. The plan here is to add an optional skipto table that contains so that computed skipto also take between O(log N) and O(1) depending on the implementation. a) a sysctl can enable or disable the table (off by default); b) the initial implementation would be a trivial array with 64k entries containing rule_id and rule_ptr (rule_nr is implicit). It consumes 512-768k of memory (the reason why I'd default to off) but is fast and reliable. As an alternative, perhaps at a later time, I might put in a version that uses a smaller array, say 256 or 4k entries, at a price of 16..256 search loops worst case (this is still 3 orders of magnitude than what we have now) 3. a hash version of 'table's Right now ipfw tables are implented as routing tables, which is great if you have to lookup a longest matching prefix, but a bit overkill if you care only for ports or jail ids, and totally uninteresting if you want to lookup flow ids, or generic sequence of bytes. My plan here is to reuse the ipfw hash tables to make them available for 'ipfw table ...' commands. To avoid code and syntax bloat, I'd use the number 0..TABLE_MAX-1 for the existing prefix tables, and TABLE_MAX..2TABLE_MAX-1 for the new hash tables. comments welcome cheers luigi