From: Phil Sutter <phil@nwl.cc>
To: Florian Westphal <fw@strlen.de>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>, netfilter-devel@vger.kernel.org
Subject: Re: iptables-nft fails to restore huge rulesets
Date: Wed, 31 Mar 2021 16:41:40 +0200 [thread overview]
Message-ID: <20210331144140.GV3158@orbyte.nwl.cc> (raw)
In-Reply-To: <20210331133510.GF17285@breakpoint.cc>
On Wed, Mar 31, 2021 at 03:35:10PM +0200, Florian Westphal wrote:
> Phil Sutter <phil@nwl.cc> wrote:
> > I'm currently trying to fix for an issue in Kubernetes realm[1]:
> > Baseline is they are trying to restore a ruleset with ~700k lines and it
> > fails. Needless to say, legacy iptables handles it just fine.
> >
> > Meanwhile I found out there's a limit of 1024 iovecs when submitting the
> > batch to kernel, and this is what they're hitting.
> >
> > I can work around that limit by increasing each iovec (via
> > BATCH_PAGE_SIZE) but keeping pace with legacy seems ridiculous:
> >
> > With a scripted binary-search I checked the maximum working number of
> > restore items of:
> >
> > (1) User-defined chains
> > (2) rules with merely comment match present
> > (3) rules matching on saddr, daddr, iniface and outiface
> >
> > Here's legacy compared to nft with different factors in BATCH_PAGE_SIZE:
> >
> > legacy 32 (stock) 64 128 256
> > ----------------------------------------------------------------------
> > 1'636'799 1'602'202 - NC - - NC - - NC -
> > 1'220'159 302'079 604'160 1'208'320 - NC -
> > 3'532'040 242'688 485'376 971'776 1'944'576
>
> Can you explain that table? What does 1'636'799 mean? NC?
Ah, sorry: NC is "not care", I didn't consider those numbers relevant
given that iptables-nft has caught up to legacy previously already.
1'636'799 is the max number of user-defined chains I can successfully
restore using iptables-legacy-restore. Looks like I dropped the rows'
description while reformatting by accident: the first row of that table
corresponds with test (1), second with test (2) and third with test (3).
So legacy may restore at once ~1.6M chains or ~1.2M comment rules or
~3.5M rules with {s,d}{addr,iface} matches.
The following columns are for iptables-nft with varying BATCH_PAGE_SIZE
values. Each of the (max 1024) iovecs passed to kernel via sendmsg() is
'N * getpagesize()' large.
Cheers, Phil
next prev parent reply other threads:[~2021-03-31 14:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-31 9:13 iptables-nft fails to restore huge rulesets Phil Sutter
2021-03-31 13:35 ` Florian Westphal
2021-03-31 14:41 ` Phil Sutter [this message]
2021-03-31 20:51 ` Pablo Neira Ayuso
2021-04-01 10:30 ` Phil Sutter
2021-04-01 11:44 ` Pablo Neira Ayuso
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=20210331144140.GV3158@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.