Efficient use of Dummynet pipes in IPFW

Luigi Rizzo rizzo at icir.org
Mon Sep 19 09:20:08 PDT 2005


On Mon, Sep 19, 2005 at 06:08:53PM +0200, Jeremie Le Hen wrote:
> Luigi, Brett,
> 
> > >in terms of implementation, if you want to add it, the best place
> > >would be to add the 'skipto' fields to each 'action' opcode.
> > >I am not very interested in implementing it, though, because i still see
> > >ipfw as a low-level language.
> 
> Is it a goal or an observation ?
> 
> > I don't see it that way, because low level languages like assembler 
> > are normally very efficient and highly granular. The underlying
> > opcode language of IPFW is low level for sure. But I would classify 
> > IPFW's "language," as presented by the userland utility, as "high 
> > level but limited." Sort of like the MS-DOS shell.
> 
> While I'm quite reluctant to complixify ipfw syntax, I must admit that
> having the possibility to negate a whole rule could speed up well-thought

original

	ipfw add 1000 dosomething cond1 cond2 cond3 cond4 cond5 ... condN

negated:

	ipfw add 1000 skipto 1001 cond1 cond2 cond3 cond4 cond5 ... condN
	ipfw add 1000 dosomething

sure if 'dosomething' is non-terminal in some cases you need 3 instead of 2
rules

skipto are extremely efficient (just a pointer dereference), almost as
efficient as it would be a 'resume' option.

cheers
luigi

> rulesets.  Efficiency _is_ a goal of ipfw.  This would certainly
> simplify some rulesets, avoiding to use De Morgan's theorem, but more
> importantly, this will also prevent to tests for N rules when you just
> want to test for the negation of N criterions.  At very high PPS, when
> pf is not an option any more but ipfw still is, this might create a gap
> with the current implementation.
> 
> OTOH, I agree with Luigi about the "resume" keyword.  This introduces
> a kind of linked-lists, but this is just syntactic sugar and I can't
> see any performance improvement with this.  This might be worth to have
> but I'm a little but scared about adding such options because there
> would be no reason then to not add other syntactic facilities, which
> would end up messing the whole syntax.
> 
> Best regards,
> -- 
> Jeremie Le Hen
> < jeremie at le-hen dot org >< ttz at chchile dot org >
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"


More information about the freebsd-net mailing list