From: Alexander Duyck <alexander.duyck@gmail•com>
To: Julian Anastasov <ja@ssi•bg>,
Alexander Duyck <alexander.h.duyck@redhat•com>
Cc: netdev@vger•kernel.org, "David S. Miller" <davem@davemloft•net>
Subject: Re: [net-next PATCH 4/4] fib_trie: Remove leaf_info
Date: Wed, 25 Feb 2015 16:16:41 -0800 [thread overview]
Message-ID: <54EE65E9.9010302@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.11.1502260124420.27068@ja.home.ssi.bg>
On 02/25/2015 04:06 PM, Julian Anastasov wrote:
> Hello,
>
> On Wed, 25 Feb 2015, Alexander Duyck wrote:
>
>>> If there is some fa in list with higher fa_slen
>>> fib_find_alias will always stop the loop and come with
>>> fa != NULL, so above 'if...break' is not needed, we are
>>> always going to add at tail when fa is NULL.
>> Actually fib_find_alias will return NULL in the case that there was a hole in
>> which the suffix length does not exist.
>>
>> So for example if we have a suffix length of 8 and one of 10 and we are adding
>> a suffix length of 9 then fib_find_alias will return NULL and we need to walk
>> though the list and find the hole we are supposed to drop the suffix in.
> I missed the fact that we return NULL instead of fa.
> I thought, it would be more consistent with the old logic
> to return a stop position. And we avoid walking the list
> again. But in practice we should not see many entries here,
> right?
Most users should have a pretty shallow list here. In the case of BGP
routes there might be more entries per slen but the odds of encountering
a NULL in that case should be pretty low.
>> Why are you showing me an example with a 32b int when I am using a long? For
>> x86 a 32b shift on a 32b value is undefined so we need to compare the suffix
>> length to the KEYLENGTH. For 64b a long value can be shifted up to 63 bits
>> and still be a defined value. That is why I use "1ul" as the value being
>> shifted and then also perform the check for KEYLENGTH vs BITS_PER_LONG in
>> order to determine if I still need the check for fa_slen != KEYLENGTH.
> I see, so, on 64-bit platform we avoid the
> KEYLENGTH check... OK, that is better.
>
> Regards
>
> --
> Julian Anastasov <ja@ssi•bg>
Yes, the BIT_PER_LONG check will be broken down to either 0 or 1 by the
complier so it will be stripped out in the resulting assembler.
- Alex
next prev parent reply other threads:[~2015-02-26 0:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-25 19:05 [net-next PATCH 0/4] fib_trie: Remove leaf_info structure Alexander Duyck
2015-02-25 19:06 ` [net-next PATCH 1/4] fib_trie: Convert fib_alias to hlist from list Alexander Duyck
2015-02-25 19:06 ` [net-next PATCH 2/4] fib_trie: Replace plen with slen in leaf_info Alexander Duyck
2015-02-25 21:15 ` Julian Anastasov
2015-02-25 21:30 ` Alexander Duyck
2015-02-25 22:43 ` Julian Anastasov
2015-02-25 22:57 ` Alexander Duyck
2015-02-25 19:06 ` [net-next PATCH 3/4] fib_trie: Add slen to fib alias Alexander Duyck
2015-02-25 19:06 ` [net-next PATCH 4/4] fib_trie: Remove leaf_info Alexander Duyck
2015-02-25 22:29 ` Julian Anastasov
2015-02-25 23:09 ` Alexander Duyck
2015-02-26 0:06 ` Julian Anastasov
2015-02-26 0:16 ` Alexander Duyck [this message]
2015-02-27 22:06 ` [net-next PATCH 0/4] fib_trie: Remove leaf_info structure 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=54EE65E9.9010302@gmail.com \
--to=alexander.duyck@gmail$(echo .)com \
--cc=alexander.h.duyck@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=ja@ssi$(echo .)bg \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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