netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Lodal <simonl@parknet.dk>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: netfilter-devel@vger.kernel.org, kaber@trash.net
Subject: Re: xt2 table core
Date: Sun, 4 Jul 2010 19:22:39 +0200	[thread overview]
Message-ID: <201007041922.39846.simonl@parknet.dk> (raw)
In-Reply-To: <alpine.LSU.2.01.1007041440130.12356@obet.zrqbmnf.qr>

Søndag 04 juli 2010 15:56:03 skrev Jan Engelhardt:
> On Friday 2010-07-02 05:32, Simon Lodal wrote:
> >> This patchset adds the xtables2 main proper, and incrementally
> >> changes ip6_tables to use it. There are more patches for iptables
> >> and arptables and, but to not make it larger than needed, just this
> >> much for now.
> >> 
> >> Previously featured on http://lwn.net/Articles/345176/ .
> >
> >Nice to see some new development! Guess we all have a long wishlist that
> >is hard to implement in the current design, and this may make it easier.
> >
> >But what about performance? I think all these lists must cause a huge
> >amount of jumps in hot path (eg. filtering packets). The packed blob
> >format is hard to work with, but once created it is efficient. Do you
> >have any expectations or even numbers on the performance?
> 
> Your suspicion was right, linked lists seem to have their impact.
> 
> The command I used was
> 
> 	ping6 localhost -fc 500 -i .001
> 
> this sends 500 packets in near-flood fashion (-i0 would lead to
> packet drops).
> 
> Xtables1 blob-style 2.6.31-rc4:
> 500 packets transmitted, 500 received, 0% packet loss, time 3532ms
> 500 packets transmitted, 500 received, 0% packet loss, time 3428ms
> 500 packets transmitted, 500 received, 0% packet loss, time 3388ms
> 500 packets transmitted, 500 received, 0% packet loss, time 3339ms
> 500 packets transmitted, 500 received, 0% packet loss, time 3219ms
> 
> Xtables1 blob-style 2.6.34:
> 500 packets transmitted, 500 received, 0% packet loss, time 3405ms
> 500 packets transmitted, 500 received, 0% packet loss, time 3525ms
> 500 packets transmitted, 500 received, 0% packet loss, time 3426ms
> 500 packets transmitted, 500 received, 0% packet loss, time 3388ms
> 500 packets transmitted, 500 received, 0% packet loss, time 3328ms
> 
> Xtables2 (linked lists) 2.6.35-rc1:
> 500 packets transmitted, 500 received, 0% packet loss, time 14775ms
> 500 packets transmitted, 500 received, 0% packet loss, time 14383ms
> 500 packets transmitted, 500 received, 0% packet loss, time 14381ms
> 500 packets transmitted, 500 received, 0% packet loss, time 15432ms
> 500 packets transmitted, 500 received, 0% packet loss, time 14498ms
> 
> nftables (uses linked lists) 2.6.31-rc4:
> 500 packets transmitted, 500 received, 0% packet loss, time 16198ms
> 500 packets transmitted, 500 received, 0% packet loss, time 16128ms
> 500 packets transmitted, 500 received, 0% packet loss, time 16492ms
> 500 packets transmitted, 500 received, 0% packet loss, time 16451ms
> 500 packets transmitted, 500 received, 0% packet loss, time 16475ms
> 
> Well I guess Xt2 isn't the total backlight :-)
> 
> Do you have any suggestions for improvement though?

Interesting.

I think it is a question of granularity. At what level do we use lists, vs. 
blobs? It seems to be a flexibility/performance tradeoff. I have hundreds of 
kpps 24/7 and rarely reload rules, so I am strictly in the performance camp 
:-)

Chain granularity that we have now is maybe too big. Match/target granularity 
that you use is apparently too small. Also, is the ability to edit matches and 
targets really useful? Perhaps rule granularity (keep each rule as one blob) 
is right.

Another thought, though beyond the scope of this patchset: The kernel side 
could have two rulesets:
1) In linked lists (like your patch), what userspace sees.
2) Big packed blobs, generated in kernel from the lists; what filtering 
actually runs off.

So userspace gets flexibility, and kernel side gets performance, plus dealing 
with packaging the blob, copying it NR_CPU times, swapping it in atomically.


Simon
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-07-04 17:22 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-29  8:42 xt2 table core Jan Engelhardt
2010-06-29  8:42 ` [PATCH 01/56] netfilter: ebtables: simplify a device in/out check Jan Engelhardt
2010-06-29  8:42 ` [PATCH 02/56] netfilter: ebtables: change ebt_basic_match to xt convention Jan Engelhardt
2010-06-29  8:42 ` [PATCH 03/56] netfilter: xtables: move functions around Jan Engelhardt
2010-06-29  8:42 ` [PATCH 04/56] netfilter: xtables: convert basic nfproto match functions into xt matches Jan Engelhardt
2010-06-29  8:42 ` [PATCH 05/56] netfilter: xtables2: initial table skeletal functions Jan Engelhardt
2010-06-29  8:42 ` [PATCH 06/56] netfilter: xtables2: initial chain " Jan Engelhardt
2010-06-29  8:42 ` [PATCH 07/56] netfilter: xtables2: initial rule " Jan Engelhardt
2010-06-29  8:42 ` [PATCH 08/56] netfilter: xtables: alternate size checking in xt_check_match Jan Engelhardt
2010-06-29  8:42 ` [PATCH 09/56] netfilter: xtables: alternate size checking in xt_check_target Jan Engelhardt
2010-06-29  8:42 ` [PATCH 10/56] netfilter: xtables2: per-rule match skeletal functions Jan Engelhardt
2010-06-29  8:42 ` [PATCH 11/56] netfilter: xtables2: per-rule target " Jan Engelhardt
2010-06-29  8:42 ` [PATCH 12/56] netfilter: xtables2: xt_check_target in combination with xt2 contexts Jan Engelhardt
2010-06-29  8:42 ` [PATCH 13/56] netfilter: xtables2: jumpstack (de)allocation functions Jan Engelhardt
2010-06-29  8:42 ` [PATCH 14/56] netfilter: xtables2: table traversal Jan Engelhardt
2010-06-29  8:42 ` [PATCH 15/56] netfilter: xtables: add xt_quota revision 3 Jan Engelhardt
2010-06-29  8:42 ` [PATCH 16/56] netfilter: xtables2: make a copy of the ipv6_filter table Jan Engelhardt
2010-06-29  8:42 ` [PATCH 17/56] netfilter: xtables2: initial xt1->xt2 translation for tables Jan Engelhardt
2010-06-29  8:42 ` [PATCH 18/56] netfilter: xtables2: xt2->xt1 translation - GET_INFO support Jan Engelhardt
2010-06-29  8:42 ` [PATCH 19/56] netfilter: xtables2: xt2->xt1 translation - GET_ENTRIES support Jan Engelhardt
2010-06-29  8:43 ` [PATCH 20/56] netfilter: xtables2: xt1->xt2 translation - SET_REPLACE support Jan Engelhardt
2010-06-29  8:43 ` [PATCH 21/56] netfilter: xtables2: return counters after SET_REPLACE Jan Engelhardt
2010-06-29  8:43 ` [PATCH 22/56] netfilter: xtables2: xt1->xt2 translation - ADD_COUNTERS support Jan Engelhardt
2010-06-29  8:43 ` [PATCH 23/56] netfilter: xtables2: xt2->xt1 translation - compat GET_INFO support Jan Engelhardt
2010-06-29  8:43 ` [PATCH 24/56] netfilter: ip6tables: move mark_chains to xt1_perproto.c Jan Engelhardt
2010-06-29  8:43 ` [PATCH 25/56] netfilter: xtables2: xt2<->xt1 translation - compat GET_ENTRIES/SET_REPLACE support Jan Engelhardt
2010-06-29  8:43 ` [PATCH 26/56] netfilter: xtables2: compat->normal match data translation Jan Engelhardt
2010-06-29  8:43 ` [PATCH 27/56] netfilter: xtables2: compat->normal target " Jan Engelhardt
2010-06-29  8:43 ` [PATCH 28/56] netfilter: xtables2: outsource code into xts_match_to_xt1 function Jan Engelhardt
2010-06-29  8:43 ` [PATCH 29/56] netfilter: xtables2: normal->compat match data translation Jan Engelhardt
2010-06-29  8:43 ` [PATCH 30/56] netfilter: xtables2: normal->compat target " Jan Engelhardt
2010-06-29  8:43 ` [PATCH 31/56] netfilter: xtables2: packet tracing Jan Engelhardt
2010-06-29  8:43 ` [PATCH 32/56] netfilter: xtables: turn procfs entries to walk xt2 table list Jan Engelhardt
2010-06-29  8:43 ` [PATCH 33/56] netfilter: xtables2: switch ip6's tables to the xt2 table format Jan Engelhardt
2010-06-29  8:47 ` xt2 table core [*/33, not */56] Jan Engelhardt
2010-07-02  3:32 ` xt2 table core Simon Lodal
2010-07-04 13:56   ` Jan Engelhardt
2010-07-04 17:22     ` Simon Lodal [this message]
2010-07-04 18:00       ` Jan Engelhardt
2010-07-05  8:55     ` Patrick McHardy
2010-07-05  9:13       ` Jan Engelhardt
2010-07-05  9:15         ` Patrick McHardy
2010-07-05  9:36     ` Eric Dumazet
2010-07-05  9:42       ` Jan Engelhardt
2010-07-05 10:22         ` Eric Dumazet
2010-07-05 10:34           ` 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=201007041922.39846.simonl@parknet.dk \
    --to=simonl@parknet.dk \
    --cc=jengelh@medozas.de \
    --cc=kaber@trash.net \
    --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;
as well as URLs for NNTP newsgroup(s).