Re: Efficient use of Dummynet pipes in IPFW

From: Luigi Rizzo (rizzo_at_icir.org)
Date: 09/19/05

  • Next message: Jeremie Le Hen: "Re: ARP behavior in FreeBSD vs Linux" 
    Date: Mon, 19 Sep 2005 09:20:03 -0700
To: Jeremie Le Hen <jeremie@le-hen.org>

    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@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-net
    > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Jeremie Le Hen: "Re: ARP behavior in FreeBSD vs Linux"

    Relevant Pages

    • Re: Efficient use of Dummynet pipes in IPFW
      ... > I don't see it that way, because low level languages like assembler ... > opcode language of IPFW is low level for sure. ... what are the abilities that you ...
      (freebsd-net)
    • Re: PostLisp, a language experiment
      ... I always liked to consider many Lisps to be low level languages. ... They're low level since they're composed of very primitive operations ...
      (comp.lang.lisp)