From owner-cvs-all Mon May 13 4:26:27 2002 Delivered-To: cvs-all@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id C214537B405; Mon, 13 May 2002 04:26:21 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g4DBQKX30937; Mon, 13 May 2002 04:26:20 -0700 (PDT) (envelope-from rizzo) Date: Mon, 13 May 2002 04:26:19 -0700 From: Luigi Rizzo To: Poul-Henning Kamp Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/net if_ethersubr.c src/sys/netinet ip_dummynet.c ip_dummynet.h Message-ID: <20020513042619.A30792@iguana.icir.org> References: <20020513034603.A30586@iguana.icir.org> <12788.1021286863@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12788.1021286863@critter.freebsd.dk> User-Agent: Mutt/1.3.23i Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, May 13, 2002 at 12:47:43PM +0200, Poul-Henning Kamp wrote: ... > But couldn't you easily add a new rulechain for the ethernet > rules ? That seems both clean and simple to me ? yes, in fact this is probably what i will end up doing. Just trying to figure out what to put in the ip_fw struct to instruct the kernel to link the rule in the other chain. > Besides, if we want to clean up, 5.0 is the time to do it... there is more to that. After looking at how bloated the code has become, i have definitely come to the conclusion that we have two choices here (not mutually exclusive): + restructure the internals of ipfw so that rules are made of an array of 'instructions' (much like bpf) which match various components of the packet or its metadata. The array contains only those elements which are in use, so we don't need a large bitmap to mark which parts of the (current) struct ip_fw we care and which ones we do not, and in the end i think they make the matching code faster. This also preserves backward compatibility (in terms of source ipfw rules). + support bpf bytecode as one of these 'instructions'. There is no point in trying to rewrite compilers and instruction sets or specialized instructions to match some of the special cases that people want. We have things like 'match this IP_ID' or 'match this TCP_ACK_NUMBER' and the like, the list can easily get out of control. With a bit of luck, I will be able to achieve the former without too much effort. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message