Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Bart De Schuymer <bdschuym@pandora.be>
To: Amin Azez <azez@ufomechanic.net>
Cc: Michael Bellion <mbellion@hipac.org>,
	netfilter-devel@lists.netfilter.org,
	netfilter@lists.netfilter.org
Subject: Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0
Date: Sun, 02 Oct 2005 11:20:40 +0000	[thread overview]
Message-ID: <1128252040.3388.15.camel@localhost.localdomain> (raw)
In-Reply-To: <433AA30E.7060709@ufomechanic.net>

Op wo, 28-09-2005 te 15:05 +0100, schreef Amin Azez:
> This auto-factorization of rules seems cool.
> 
> > Dynamic rule sets:
> > nf-HiPAC offers fast dynamic rules et updates without stalling packet
> >classification in contrast to iptables which yields bad update performance
> > along with stalled packet processing during updates.
> 
> Does it also remove the "upload rules in bulk" issue of iptables and
> make use of links lists (or trees) to upload small changes singly? I
> recall someone released a re-write a while ago that took care of this,
> but this seems to do rule-factoring too to reduce the number of check
> operations.
> 
> Speaking under fear of blasphemy I'm wondering what stops this becoming
> iptables proper? (ipv4 anyway)?  OK, it would want linking to
> nf_conntrack instead of ip_conntrack and a v6 version doing type stuff,
> but it seems the biz.

http://www.hipac.org/documentation/user_guide.html states some
incompatibilities with iptables.

What's always resisted me from looking to it closely is that there is no
documentation about the implementation. I'm especially interested in how
the code deals with matches. The reason why counters aren't supported
interests me too, I can't see why adding 1 to a 64-bit integer would
result in a noticeable performance drop.
Also, is it not possible to make a B+ tree with the standard iptables? I
don't see why it shouldn't be possible. The jump to a new chain can be
seen as going deeper into the B+ tree. So it should be possible to
construct an iptables table structure that looks very similar to the B+
tree of nf-hipac, for some given rule set. I guess this will be somewhat
slower than nf-hipac, but I'd like to see the performance difference...

cheers,
Bart




  parent reply	other threads:[~2005-10-02 11:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-26  2:41 [ANNOUNCE] Release of nf-HiPAC 0.9.0 Michael Bellion
2005-09-28 14:05 ` Amin Azez
2005-09-28 19:46   ` Henrik Nordstrom
2005-10-02 11:20   ` Bart De Schuymer [this message]
2005-10-02 12:30     ` Michael Bellion
2005-11-09 22:35       ` Bart De Schuymer
2005-11-10  1:07         ` Michael Bellion

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1128252040.3388.15.camel@localhost.localdomain \
    --to=bdschuym@pandora.be \
    --cc=azez@ufomechanic.net \
    --cc=mbellion@hipac.org \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox