Robert Olsson a écrit :
Stephen Hemminger writes:
> This is how I did it:
Yes looks like an elegant solution. Did you even test it?
Maybe we see some effects in just dumping a full table?
Anyway lookup should be tested in some way. We can a lot
of analyzing before getting to right entry,
Stephen Hemminger writes:
> This is how I did it:
Yes looks like an elegant solution. Did you even test it?
Maybe we see some effects in just dumping a full table?
Anyway lookup should be tested in some way. We can a lot
of analyzing before getting to right entry, local_table
backtracking
On Tue, 15 Jan 2008 10:15:43 -0800
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Jan 2008 19:10:31 +0100
> Eric Dumazet <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 15 Jan 2008 09:47:53 -0800
> > Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> >
> > > This is how I did it:
> > >
> > > --
On Tue, 15 Jan 2008 19:10:31 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Jan 2008 09:47:53 -0800
> Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> > This is how I did it:
> >
> > --- a/net/ipv4/fib_trie.c 2008-01-15 09:14:53.0 -0800
> > +++ b/net/ipv4/fib_trie.c 2008-
On Tue, 15 Jan 2008 09:47:53 -0800
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> This is how I did it:
>
> --- a/net/ipv4/fib_trie.c 2008-01-15 09:14:53.0 -0800
> +++ b/net/ipv4/fib_trie.c 2008-01-15 09:21:48.0 -0800
> @@ -101,13 +101,6 @@ struct node {
> t_key key;
Eric Dumazet writes:
>
> So you think that a leaf cannot have 2 infos, one 'embeded' and one in the
> list ?
Hello,
The model I thought of is to have either:
1) One leaf_info embedded in leaf. A fast-path leaf. FP-leaf
Or
2) The intct old leaf_info list with arbitrary number leaf
This is how I did it:
--- a/net/ipv4/fib_trie.c 2008-01-15 09:14:53.0 -0800
+++ b/net/ipv4/fib_trie.c 2008-01-15 09:21:48.0 -0800
@@ -101,13 +101,6 @@ struct node {
t_key key;
};
-struct leaf {
- unsigned long parent;
- t_key key;
- struct h
On Tue, 15 Jan 2008 17:44:47 +0100
Robert Olsson <[EMAIL PROTECTED]> wrote:
>
> Stephen Hemminger writes:
>
> > Okay, I would rather see the leaf_info explicit inside the leaf, also
> > your scheme probably breaks if I add two prefixes and then delete the
> first.
> > Let me have a go at it.
Stephen Hemminger writes:
> Okay, I would rather see the leaf_info explicit inside the leaf, also
> your scheme probably breaks if I add two prefixes and then delete the first.
> Let me have a go at it.
I took Eric's patch a bit further...
Support for delete and dump is needed before any
On Tue, 15 Jan 2008 07:16:30 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Eric Dumazet a écrit :
> > Stephen Hemminger a écrit :
> >> Combine the prefix information and the leaf together into one
> >> allocation. This is furthur simplified by converting the hlist
> >> into a simple bitfield.
>
Eric Dumazet a écrit :
Stephen Hemminger a écrit :
Combine the prefix information and the leaf together into one
allocation. This is furthur simplified by converting the hlist
into a simple bitfield.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
This patch is experimental (ie it boots a
Stephen Hemminger a écrit :
Combine the prefix information and the leaf together into one
allocation. This is furthur simplified by converting the hlist
into a simple bitfield.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
This patch is experimental (ie it boots and loads routes), but
is
Combine the prefix information and the leaf together into one
allocation. This is furthur simplified by converting the hlist
into a simple bitfield.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
This patch is experimental (ie it boots and loads routes), but
is slower for the 163,000 route
13 matches
Mail list logo
