From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 15:49:18 2014 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5361A325 for ; Thu, 5 Jun 2014 15:49:18 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 108862C48 for ; Thu, 5 Jun 2014 15:49:17 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5E8F57300A; Thu, 5 Jun 2014 17:54:02 +0200 (CEST) Date: Thu, 5 Jun 2014 17:54:02 +0200 From: 'Luigi Rizzo' To: bycn82 Subject: Re: [CFT]: ipfw named tables / different tabletypes Message-ID: <20140605155402.GA81905@onelab2.iet.unipi.it> References: <20140521204826.GA67124@onelab2.iet.unipi.it> <537E1029.70007@FreeBSD.org> <20140522154740.GA76448@onelab2.iet.unipi.it> <537E2153.1040005@FreeBSD.org> <20140522163812.GA77634@onelab2.iet.unipi.it> <538B2FE5.6070407@FreeBSD.org> <539044E4.1020904@ipfw.ru> <000c01cf80be$41194370$c34bca50$@gmail.com> <20140605134256.GA81234@onelab2.iet.unipi.it> <000001cf80cd$5dc1d9b0$19458d10$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <000001cf80cd$5dc1d9b0$19458d10$@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "'Alexander V. Chernikov'" , 'FreeBSD Net' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 15:49:18 -0000 On Thu, Jun 05, 2014 at 10:49:27PM +0800, bycn82 wrote: > Hi Luigi, > Yes, use string instead of integer for the ID of table, but the same method cannot apply to the feature `set type of table`. And in the kernel, compare string will cause more than compare an integer. In my opinion, actually they are just alias name for the object. Users already accept that every object has an integer ID. Bill, I appreciate your enthusiasm on contributing to the project, but before starting to code, you (and everyone else, including myself) should spend some time at the drawing board, question your assumptions, and consider possible implementations. Also the fact that previous implementations had bugs or restrictions does not imply that we should repeat the same mistakes now. Specifically: - comparing strings in the kernel is perfectly fine, we do it all the time (sysctl names, filenames, interfaces and whatnot). What would be terribly wrong is having to do, on every packet, an expensive string or number lookup (note- it's the entire lookup process, not a string comparison) to locate the table. However, this is not the case.   The way to implement named objects (tables etc.) is to accept strings   as object names, and when the rule is added the string is checked and converted to a pointers or an integer which permits direct access to the table. This is as fast as it can be at runtime, which is all what matters. - at the moment tables and pipes have a single ID, which happens to be a sequence of digits for mostly historical reasons (you can read it as laziness of the original authors; i can take the blame for pipes). If we extend the namespace to include strings we improve the user's experience and remain compatible with the existing user interface. Instead, if we require users to create a mapping before using alphanumeric names, not only we add a step that was not there before, but also create two names for the same object which makes it harder to reason about the rulesets, and there is also the issue of how to handle references to non-existing tables (which are trivially supported now or with the approach i suggested, and would instead require rescanning the ruleset whenever a name-number association is added or deleted. Another troubles with that approach is that you opening a race window between the creation of the name-number mapping and its use, and this is also something you don't want in a security-related tool. We have had a similar discussion about your 'pps' extension for ipfw: useful feature, but your various implementations have issues (even the final one), and we have only so much time for reviewing patches; please do not burn it. cheers luigi