From: Stephen Hemminger <shemminger@vyatta.com>
To: David Miller <davem@davemloft.net>
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org
Subject: Re: [PATCH] ipv4: Remove fib_hash.
Date: Wed, 2 Feb 2011 08:29:21 -0800 [thread overview]
Message-ID: <20110202082921.7eee82e0@nehalam> (raw)
In-Reply-To: <20110201.181542.193701016.davem@davemloft.net>
On Tue, 01 Feb 2011 18:15:42 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@gmail.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.
--
next prev parent reply other threads:[~2011-02-02 16:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 23:19 [PATCH] ipv4: Remove fib_hash David Miller
2011-02-01 23:26 ` Stephen Hemminger
2011-02-01 23:33 ` Stephen Hemminger
2011-02-01 23:35 ` David Miller
2011-02-02 0:48 ` Eric Dumazet
2011-02-02 2:15 ` David Miller
2011-02-02 16:29 ` Stephen Hemminger [this message]
2011-02-02 21:51 ` David Miller
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=20110202082921.7eee82e0@nehalam \
--to=shemminger@vyatta.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@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).