netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Does the ordering of the fib_table_dump or /proc/net/fib_trie matter?
@ 2015-01-06 20:30 Alexander Duyck
  2015-01-06 21:58 ` David Miller
  0 siblings, 1 reply; 3+ messages in thread
From: Alexander Duyck @ 2015-01-06 20:30 UTC (permalink / raw)
  To: miller >> David Miller, stephen, NetDev

I am considering reversing the order of any non-lookup traversal of the
fib_trie so that it starts at the last node and works it's way up toward
the first node.  This would make it so that all walks using the parent
pointer all go in the same direction.

The problem right now is that leaf_walk_rcu and a couple of other
iterators traverse the trie in one direction grabbing the next child
(child++) of the parent, while fib_table_lookup is traversing the list
grabbing a previous child (child & (child - 1)) of the parent.  It makes
things a bit ugly for RCU as we have to have the node fully populated
before we can start updating the parent pointers on the children.

I want to have them both moving in the same direction so the
fib_table_lookup would remain the same, but the leaf_walk_rcu and others
would walk from the last child to the first (child--) and as a result
when I assemble a tnode in inflate or halve I would be able to populate
children from 0 to ((1 << tn->bits) - 1) without having to worry about
any iterators walking into uninitialized memory.

The question I have is if that would screw up any user-space apps.  I
know ip route can dump the list via "ip route show".  I'm just wondering
if there would be any problem with default being the last entry instead
of the first entry?

- Alex

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Does the ordering of the fib_table_dump or /proc/net/fib_trie matter?
  2015-01-06 20:30 Does the ordering of the fib_table_dump or /proc/net/fib_trie matter? Alexander Duyck
@ 2015-01-06 21:58 ` David Miller
  2015-01-07  0:58   ` Alexander Duyck
  0 siblings, 1 reply; 3+ messages in thread
From: David Miller @ 2015-01-06 21:58 UTC (permalink / raw)
  To: alexander.duyck; +Cc: stephen, netdev

From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Tue, 06 Jan 2015 12:30:06 -0800

> The question I have is if that would screw up any user-space apps.  I
> know ip route can dump the list via "ip route show".  I'm just wondering
> if there would be any problem with default being the last entry instead
> of the first entry?

The ordering already changed once when we went from fib_hash to
fib_trie, nobody should depend upon the ordering.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Does the ordering of the fib_table_dump or /proc/net/fib_trie matter?
  2015-01-06 21:58 ` David Miller
@ 2015-01-07  0:58   ` Alexander Duyck
  0 siblings, 0 replies; 3+ messages in thread
From: Alexander Duyck @ 2015-01-07  0:58 UTC (permalink / raw)
  To: David Miller; +Cc: stephen, netdev

On 01/06/2015 01:58 PM, David Miller wrote:
> From: Alexander Duyck <alexander.duyck@gmail.com>
> Date: Tue, 06 Jan 2015 12:30:06 -0800
>
>> The question I have is if that would screw up any user-space apps.  I
>> know ip route can dump the list via "ip route show".  I'm just wondering
>> if there would be any problem with default being the last entry instead
>> of the first entry?
> The ordering already changed once when we went from fib_hash to
> fib_trie, nobody should depend upon the ordering.

Okay good to hear.  I kind of thought that was the case, but I wanted to
make sure before I went too far down this rabbit hole.

Thanks.

- Alex

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-01-07  0:58 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-06 20:30 Does the ordering of the fib_table_dump or /proc/net/fib_trie matter? Alexander Duyck
2015-01-06 21:58 ` David Miller
2015-01-07  0:58   ` Alexander Duyck

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).