[iptables] libiptc: fix scalability performance issue during initial ruleset parsing

Patrick McHardy netfilter-cvslog-bounces at lists.netfilter.org
Thu Jul 3 20:45:55 CEST 2008


Gitweb:		http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a=commit;h=4bae3f1001028ee283a5e1fcea4a561b0068f95d
commit 4bae3f1001028ee283a5e1fcea4a561b0068f95d
Author:     Jesper Dangaard Brouer <hawk at comx.dk>
AuthorDate: Thu Jul 3 20:31:42 2008 +0200
Commit:     Patrick McHardy <kaber at trash.net>
CommitDate: Thu Jul 3 20:31:42 2008 +0200

    libiptc: fix scalability performance issue during initial ruleset parsing
    
     Finding jump chains is slow O(Chain*Rules).
    
    The problem:
     is that the chain list is searched lineary for each rule with a jump
     target. The problem lies in the "second pass" (of function
     parse_table) where the userchain jump targets are found. For each
     rule "R" with a IPTCC_R_JUMP target, function
     iptcc_find_chain_by_offset() searches through the chains "C" in the
     chain list (worst-case hitting the last one).
    
    The solution:
     in this patch is to speed up iptcc_find_chain_by_offset() by using
     binary search. Reducing complexity from O(C) to O(log C).
    
    Implementation:
     Its possible to use the same bsearch algorithm and data structure
     (chain_index), as used for chain name searching.
    
    How is that possible:
     One has to realize that the chains are both sorted by name and
     offsets, this is because the chains are already sorted in the ruleset
     from the kernel.
    
    Signed-off-by: Jesper Dangaard Brouer <hawk at comx.dk>
    Signed-off-by: Patrick McHardy <kaber at trash.net>

commit 526d3e138635e33773d1ca16477052a04f53f5bd
Author:     Jesper Dangaard Brouer <hawk at comx.dk>
AuthorDate: Thu Jul 3 20:29:34 2008 +0200
Commit:     Patrick McHardy <kaber at trash.net>
CommitDate: Thu Jul 3 20:29:34 2008 +0200

    libiptc: minor bugfix
    
    Minor bugfix, an extra check is needed if the tail element is a
    builtin chain, as builtin chains are not sorted.
    
    Signed-off-by: Jesper Dangaard Brouer <hawk at comx.dk>
    Signed-off-by: Patrick McHardy <kaber at trash.net>
       via  4bae3f1001028ee283a5e1fcea4a561b0068f95d (commit)
       via  526d3e138635e33773d1ca16477052a04f53f5bd (commit)
      from  55dffefc95151b5746a853c8ed71097d7b5a8575 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 4bae3f1001028ee283a5e1fcea4a561b0068f95d
Author: Jesper Dangaard Brouer <hawk at comx.dk>
Date:   Thu Jul 3 20:31:42 2008 +0200

    libiptc: fix scalability performance issue during initial ruleset parsing
    
     Finding jump chains is slow O(Chain*Rules).
    
    The problem:
     is that the chain list is searched lineary for each rule with a jump
     target. The problem lies in the "second pass" (of function
     parse_table) where the userchain jump targets are found. For each
     rule "R" with a IPTCC_R_JUMP target, function
     iptcc_find_chain_by_offset() searches through the chains "C" in the
     chain list (worst-case hitting the last one).
    
    The solution:
     in this patch is to speed up iptcc_find_chain_by_offset() by using
     binary search. Reducing complexity from O(C) to O(log C).
    
    Implementation:
     Its possible to use the same bsearch algorithm and data structure
     (chain_index), as used for chain name searching.
    
    How is that possible:
     One has to realize that the chains are both sorted by name and
     offsets, this is because the chains are already sorted in the ruleset
     from the kernel.
    
    Signed-off-by: Jesper Dangaard Brouer <hawk at comx.dk>
    Signed-off-by: Patrick McHardy <kaber at trash.net>

commit 526d3e138635e33773d1ca16477052a04f53f5bd
Author: Jesper Dangaard Brouer <hawk at comx.dk>
Date:   Thu Jul 3 20:29:34 2008 +0200

    libiptc: minor bugfix
    
    Minor bugfix, an extra check is needed if the tail element is a
    builtin chain, as builtin chains are not sorted.
    
    Signed-off-by: Jesper Dangaard Brouer <hawk at comx.dk>
    Signed-off-by: Patrick McHardy <kaber at trash.net>

-----------------------------------------------------------------------

 libiptc/libiptc.c |  126 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 114 insertions(+), 12 deletions(-)
Minor bugfix, an extra check is needed if the tail element is a
builtin chain, as builtin chains are not sorted.

Signed-off-by: Jesper Dangaard Brouer <hawk at comx.dk>
Signed-off-by: Patrick McHardy <kaber at trash.net>

diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c
index d0f51b4..ec5317b 100644
--- a/libiptc/libiptc.c
+++ b/libiptc/libiptc.c
@@ -819,7 +819,8 @@ static void __iptcc_p_add_chain(TC_HANDLE_T h, struct chain_head *c,
 		list_add_tail(&c->list, &h->chains);
 	else {
 		ctail = list_entry(tail, struct chain_head, list);
-		if (strcmp(c->name, ctail->name) > 0)
+		if (strcmp(c->name, ctail->name) > 0 ||
+		    iptcc_is_builtin(ctail))
 			list_add_tail(&c->list, &h->chains);/* Already sorted*/
 		else
 			iptc_insert_chain(h, c);/* Was not sorted */



More information about the netfilter-cvslog mailing list