From: Ed W <lists@wildgooses.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: Jan Engelhardt <jengelh@medozas.de>,
Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: ipables and caching
Date: Sun, 29 Jan 2012 23:28:01 +0000 [thread overview]
Message-ID: <4F25D601.6010400@wildgooses.com> (raw)
In-Reply-To: <9B90546135A9F09A0A6271DF@Ximines.local>
On 27/01/2012 13:11, Alex Bligh wrote:
> Jan,
>
> --On 24 January 2012 17:29:35 +0100 Jan Engelhardt
> <jengelh@medozas.de> wrote:
>
>>> I have a legacy application which forwards lots of packets (router,
>>> essentially) and uses a lot of sometimes badly written autogenerated
>>> iptables rules (about 3,000 of them).
>>>
>>> I am seeing on a good day high route cache efficiency. Do packets
>>> which do not follow the slow path (i.e. cache hits) also cache
>>> what iptables rules they hit? Nothing fancy in use bar conn_track.
>>
>> Whether the route lookup was satisfied by cache or not plays no role
>> for Xtables execution.
>
> Thanks. I don't suppose you know of any work on caching iptables lookups
> (which I appreciate is non-trivial to impossible in the general case) or
> non-linearising lookups? I am thinking of rules in the FORWARD chain
> which
> either select by source prefix or interface (or the destination
> equivalent)
> and if the criterion is met, jump to another rule. Currently that
> search in
> linear (i.e. through every rule) which with a large number of
> prefixes/interfaces is problematic, but with a btree or similar could be
> O(log(n)), and with a hash O(1).
>
I don't think so, but have you considered adding some optimisation into
the auto generated rules? With so many rules there must surely be some
low hanging fruit to add some conditional chains to reduce the number of
rules hit? ipsets are also a very useful option to collapse certain
types of problem into fewer rules?
Good luck
Ed W
next prev parent reply other threads:[~2012-01-29 23:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-24 14:28 ipables and caching Alex Bligh
2012-01-24 16:29 ` Jan Engelhardt
2012-01-27 13:11 ` Alex Bligh
2012-01-29 23:28 ` Ed W [this message]
2012-01-30 0:00 ` Jan Engelhardt
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=4F25D601.6010400@wildgooses.com \
--to=lists@wildgooses.com \
--cc=alex@alex.org.uk \
--cc=jengelh@medozas.de \
--cc=netfilter@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