[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 2 Feb 2011 08:29:21 -0800
From: Stephen Hemminger <shemminger@...tta.com>
To: David Miller <davem@...emloft.net>
Cc: eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv4: Remove fib_hash.
On Tue, 01 Feb 2011 18:15:42 -0800 (PST)
David Miller <davem@...emloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Wed, 02 Feb 2011 01:48:13 +0100
>
> > Hmm... I know having to maintain two implementations is time consuming,
> > but I know fib_trie is bigger :
> >
> > # size net/ipv4/fib_*.o
> > text data bss dec hex filename
> > 7252 120 0 7372 1ccc net/ipv4/fib_frontend.o
> > 7279 16 4 7299 1c83 net/ipv4/fib_hash.o
> > 1479 0 0 1479 5c7 net/ipv4/fib_rules.o
> > 7885 0 2080 9965 26ed net/ipv4/fib_semantics.o
> > 16222 16 16 16254 3f7e net/ipv4/fib_trie.o
> >
> > In my tests, I know that fib_trie is more expensive for typical routing
> > tables for hosts (no more than a dozen or entries), in latencies
> > results, mostly because of icache misses, but also dcache ones.
>
> It's mostly the rebalancing code that takes up the space.
>
> The lookup path is on the same order of magnitude as the fib hash
> stuff was.
>
> In any event, we have several months to hash out any regressions and I
> think if I didn't do this removal nobody would work on it so... :-)
For the case of small devices, what about keeping fib_hash as option
under CONFIG_EMBEDDED. And remove all the magic resizing of hash table.
Get back to something with really small size.
--
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists