From: Patrick McHardy <kaber@trash.net>
To: Thomas Jacob <jacob@internet24.de>
Cc: jdb@comx.dk, netfilter-devel@vger.kernel.org
Subject: Re: Patches solving the same issue!?
Date: Thu, 03 Jul 2008 16:33:32 +0200 [thread overview]
Message-ID: <486CE33C.7080804@trash.net> (raw)
In-Reply-To: <1215095403.26474.103.camel@enterprise.ims-firmen.de>
Thomas Jacob wrote:
> On Thu, 2008-07-03 at 14:42 +0200, Patrick McHardy wrote:
>> Please work this out among yourselves. I think we should just pick
>> the faster one since both don't look very intrusive.
>
> Well, Jesper's version doesn't build any extra data-structures,
> so you save time&space there, and the offsets stuff is really
> only needed once, so the chain_index rebuilding penalty
> doesn't play a role.
>
> And since about 2/3s of time it takes to load my 50k Chains now
> is system time, it's probably irrelevant whether
> 0 + O(n * (log(n/40)+40)) is sometimes larger than O(n+n/1024) +
> O(log(n)).
>
> Mine vs. Jesper's:
>
> iptables-restore (50k chains, 120k rules), average for 10 runs:
>
> User: 2.558 s - System: 8.672 s - Total : 11.222 s
> vs
> User: 2.622 s - System: 8.520 s - Total : 11.140 s
>
>
> iptables -vnL SOMECHAIN (2 entries, with the above ruleset in kernel),
> average for 20 runs
>
> User: .094 s - System: .363 s - Total : .455 s
> vs
> User: .085 s - System: .389 s - Total : .472 s
>
> Those numbers are all within the standard deviations of each other,
> so there is no difference for practical purposes, I think :-)
>
> I would use Jesper's patch.
OK, thanks for the numbers and sorting this out so peacefully :)
next prev parent reply other threads:[~2008-07-03 14:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-02 18:00 [PATCH 0/3] Further speedup of iptables when modifying an existing ruleset Thomas Jacob
2008-07-02 18:00 ` [PATCH 1/3] Speed up verdict to chain_head mapping by using binary search Thomas Jacob
2008-07-02 18:00 ` [PATCH 2/3] Spelling Thomas Jacob
2008-07-02 18:00 ` [PATCH 3/3] Coding style Thomas Jacob
2008-07-02 20:57 ` Patches solving the same issue!? Jesper Dangaard Brouer
2008-07-02 21:47 ` Thomas Jacob
2008-07-02 22:02 ` Thomas Jacob
2008-07-03 10:53 ` Jesper Dangaard Brouer
2008-07-03 11:17 ` Thomas Jacob
2008-07-03 12:42 ` Patrick McHardy
2008-07-03 14:30 ` Thomas Jacob
2008-07-03 14:33 ` Patrick McHardy [this message]
2008-07-04 7:09 ` Jesper Dangaard Brouer
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=486CE33C.7080804@trash.net \
--to=kaber@trash.net \
--cc=jacob@internet24.de \
--cc=jdb@comx.dk \
--cc=netfilter-devel@vger.kernel.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