From: Alexander Duyck <alexander.h.duyck@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [net-next PATCH 0/6] ipv4/fib_trie: Cleanups to prepare for introduction of key vector
Date: Wed, 04 Mar 2015 06:51:27 -0800 [thread overview]
Message-ID: <54F71BEF.5030706@redhat.com> (raw)
In-Reply-To: <20150304.001640.1653151786060996185.davem@davemloft.net>
On 03/03/2015 09:16 PM, David Miller wrote:
> From: Alexander Duyck <alexander.h.duyck@redhat.com>
> Date: Mon, 02 Mar 2015 13:32:16 -0800
>
>> This patch series is meant to mostly just clean up the fib_trie to prepare
>> it for the introduction of the key_vector. As such there are a number of
>> minor clean-ups such as reformatting the tnode to match the format once the
>> key vector is introduced, some optimizations to drop the need for a leaf
>> parent pointer, and some changes to remove duplication of effort such as
>> the 2 look-ups that were essentially being done per node insertion.
> This doesn't compile with trie stats enabled, I see something sneaking
> in from the main/local table collapsing patch :-)
>
> net/ipv4/fib_trie.c: In function ‘__trie_free_rcu’:
> net/ipv4/fib_trie.c:1601:36: error: ‘struct fib_table’ has no member named ‘data’
> struct trie *t = (struct trie *)tb->data;
Ugh, sorry about that I will fix it this morning.
> Also, two comments:
>
> 1) When you go "if (idx >> n->bits)", can n->bits be == 32? If so, this
> expression is undefined.
If bits can be 32 then idx should be an unsigned long which is 64 bits.
I will double check to make sure that is still the case.
The general idea is if a long is 32 bits then we likely cannot allocate
a 32 bit tnode since that would more than consume all of the available
memory in the system. I can look into adding a comment to that effect
somewhere.
> 2) In your simplification of fib_find_node(), don't keep storing over
> and over again into the on-stack variable '*tp', instead just maintain
> a one behind pointer in a local variable for the parent, and store it
> one time as your exit the function.
>
> Thanks.
Okay I will update it. As I recall that is what the compiler ends up
doing anyway since fib_find_node ends up being inlined leaving the
parent as just a local variable.
- Alex
next prev parent reply other threads:[~2015-03-04 14:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-02 21:32 [net-next PATCH 0/6] ipv4/fib_trie: Cleanups to prepare for introduction of key vector Alexander Duyck
2015-03-02 21:32 ` [net-next PATCH 1/6] fib_trie: Only resize tnodes once instead of on each leaf removal in fib_table_flush Alexander Duyck
2015-03-02 21:32 ` [net-next PATCH 2/6] fib_trie: Fib walk rcu should take a tnode and key instead of a trie and a leaf Alexander Duyck
2015-03-02 21:32 ` [net-next PATCH 3/6] fib_trie: Fib find node should return parent Alexander Duyck
2015-03-02 21:32 ` [net-next PATCH 4/6] fib_trie: Update insert and delete to make use of tp from find_node Alexander Duyck
2015-03-02 21:32 ` [net-next PATCH 5/6] fib_trie: move leaf and tnode to occupy the same spot in the key vector Alexander Duyck
2015-03-02 21:32 ` [net-next PATCH 6/6] fib_trie: Make fib_table rcu safe Alexander Duyck
2015-03-04 5:16 ` [net-next PATCH 0/6] ipv4/fib_trie: Cleanups to prepare for introduction of key vector David Miller
2015-03-04 14:51 ` Alexander Duyck [this message]
2015-03-04 17:53 ` David Miller
2015-03-04 18:22 ` Alexander Duyck
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=54F71BEF.5030706@redhat.com \
--to=alexander.h.duyck@redhat.com \
--cc=davem@davemloft.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.