From: "David S. Miller" <davem@davemloft.net>
To: hadi@cyberus.ca
Cc: netdev@oss.sgi.com
Subject: Re: [PATCH] Clean up fib_hash datastructures
Date: Sun, 19 Sep 2004 19:53:51 -0700 [thread overview]
Message-ID: <20040919195351.0b3560e6.davem@davemloft.net> (raw)
In-Reply-To: <1095645106.1048.190.camel@jzny.localdomain>
On 19 Sep 2004 21:51:46 -0400
jamal <hadi@cyberus.ca> wrote:
> I wasnt %100 sure about the need to
> separate fib node into those two. It seems to complicate things.
> If you want to allow introduction of new algos, then fib_node itself is
> gonna have to go as well IMO. Its an artifact or current alg.
> I am actually thinking nothing at all stays of fib_hash.c for any new
> algorithm. Infact thats the only new piece/file that a new algorithm
> should write.
There are two problems. Well, logically one, which is the seperation
out of fib_node from the code.
I need to expose the layout of fib_node for other reasons.
If you look at Ben LaHaise's case, the issue becomes evident.
Firstly, fib_semantics was not designed to scale at all,
thus last weeks patches to add the hash tables. That takes
care of half of his problems, the other half is because of
fn_hash_flush() and is what is relevant to this discussion.
fn_hash_flush() walks the entire table of routes looking for
routes pointing to fib_info objects which are RTNH_F_DEAD.
The simple solution is to make fib_info contain a list of
fib_node objects, then when code marks a fib_info as RTNH_F_DEAD
we just walk the list and kill the fib_node objects directly.
But because the layout of fib_node entirely is hidden in
fib_hash.c, and we want to allow pluggable lookup implementations,
something has to give.
So the general idea I was after was:
1) All things performing pure longest-matching prefix
lookup on an ipv4 address is confined to fib_node objects
and the actual lookup algorithm.
2) Everything that occurs once we have a matching fib_node
object, is consolidated into a common pieces of code
that does all the TOS, priority, et al. magic
Anyways, we can do this differently. But at least with my
patch we have the means to do _something_.
> BTW, one thought to improve perfomance is to change the linked list in
> each of the buckets away from a linked list.
Come again? I'm a little slow today, you'll have to be a bit
more explicit about what your idea is exactly :-)
next prev parent reply other threads:[~2004-09-20 2:53 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-19 3:33 [PATCH] Clean up fib_hash datastructures David S. Miller
2004-09-20 0:39 ` jamal
2004-09-20 2:46 ` David S. Miller
2004-09-20 3:14 ` Herbert Xu
2004-09-20 3:17 ` David S. Miller
2004-09-20 13:33 ` jamal
2004-09-20 1:51 ` jamal
2004-09-20 2:53 ` David S. Miller [this message]
2004-09-20 13:24 ` jamal
2004-09-20 19:11 ` David S. Miller
2004-09-21 3:42 ` Herbert Xu
2004-09-21 6:18 ` David S. Miller
2004-09-21 9:04 ` Andi Kleen
2004-09-21 9:32 ` Herbert Xu
2004-09-21 11:03 ` jamal
2004-09-21 12:07 ` Andi Kleen
2004-09-21 12:22 ` jamal
2004-09-21 23:38 ` Steven Blake
2004-09-22 3:10 ` jamal
2004-09-22 11:56 ` Steven Blake
2004-09-22 12:12 ` jamal
2004-09-22 20:04 ` Steven Blake
2004-09-22 2:07 ` Herbert Xu
2004-09-22 2:32 ` David S. Miller
2004-09-22 3:57 ` [IPv4] Check PAGE_SIZE in fz_hash_alloc Herbert Xu
2004-09-23 20:05 ` David S. Miller
2004-09-22 3:30 ` [PATCH] Clean up fib_hash datastructures jamal
2004-09-22 3:36 ` David S. 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=20040919195351.0b3560e6.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=hadi@cyberus.ca \
--cc=netdev@oss.sgi.com \
/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).