Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 May 2002 04:26:19 -0700
From:      Luigi Rizzo <luigi@FreeBSD.org>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
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>
In-Reply-To: <12788.1021286863@critter.freebsd.dk>
References:  <20020513034603.A30586@iguana.icir.org> <12788.1021286863@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020513042619.A30792>