Linux Netfilter discussions
 help / color / mirror / Atom feed
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



  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