From: Roberto Nibali <ratz@tac.ch>
To: Michael <mutk@iprimus.com.au>
Cc: netfilter@lists.netfilter.org
Subject: Re: IPTables Feature set and performance.
Date: Wed, 04 Dec 2002 14:17:00 +0100 [thread overview]
Message-ID: <3DEE004C.1010102@tac.ch> (raw)
In-Reply-To: 3DEBEB33.2070806@iprimus.com.au
Hi,
> In addition to this, I have found one mention of throughput capabilities
> of iptables. According to this reference :http://www.hipac.org/ (The
> performance test links), iptables does have significant limitation of
> throughput when large (Sequential) rulesets are used. I believe under
Exactly.
> ideal circumstances, and with carefull attention paid the impact can be
> minimised.
Exactly.
But simply consider the fact that some people do not write their fw rules by
hand, they generate it via a meta language layer. It is apparent that the
generation of rulesets which span over multiple packet filter instances are
implicit non-optimised.
Also consider the fact that the way nf-hipac is implemented, the matching rule
lookup will always be equally or faster to netfilter's table lookup per
definition and code.
> I haven't replicated the tests, and also do not know how authoritative
> the tests are.
Preliminary tests were done by me and you can certainly consider them to be
authoritative. Unfortunately due to health reasons and limited spare time I had
to stop further tests. I will pick up the conduct of tests maybe in the
beginning of next year. Together with a friend of mine I've also written a paper
(for a link, please search this mailinglist archive) about the inefficiencies of
various rule matching algorithms based on observation, pragmatic testing and
code reading.
> If the tests results are accurate, this might help in making comparisons
> and decision making. Does anyone have evidence to backup the findings of
> nf-hipac peaple?
I do have some numbers and I have posted them to various mailinglists. Also if
you go to the nf-hipac page itself, you see a quite a convincing test result.
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
next prev parent reply other threads:[~2002-12-04 13:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-02 21:33 IPTables Feature set and performance hard__ware
2002-12-02 23:22 ` Michael
2002-12-04 13:17 ` Roberto Nibali [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-12-02 18:25 ccmike
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=3DEE004C.1010102@tac.ch \
--to=ratz@tac.ch \
--cc=mutk@iprimus.com.au \
--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