[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sidkoiu3.fsf@x220.int.ebiederm.org>
Date: Wed, 04 Mar 2015 09:58:28 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Andy Gospodarek <gospo@...ulusnetworks.com>
Cc: David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] neigh: Factor out ___neigh_lookup_noref
Andy Gospodarek <gospo@...ulusnetworks.com> writes:
> On Tue, Mar 03, 2015 at 05:10:44PM -0600, Eric W. Biederman wrote:
>>
>> While looking at the mpls code I found myself writing yet another
>> version of neigh_lookup_noref. We currently have __ipv4_lookup_noref
>> and __ipv6_lookup_noref.
>>
>> So to make my work a little easier and to make it a smidge easier to
>> verify/maintain the mpls code in the future I stopped and wrote
>> ___neigh_lookup_noref. Then I rewote __ipv4_lookup_noref and
>> __ipv6_lookup_noref in terms of this new function. I tested my new
>> version by verifying that the same code is generated in
>> ip_finish_output2 and ip6_finish_output2 where these functions are
>> inlined.
>>
>> To get to ___neigh_lookup_noref I added a new neighbour cache table
>> function key_eq. So that the static size of the key would be
>> available.
>>
>> I also added __neigh_lookup_noref for people who want to to lookup
>> a neighbour table entry quickly but don't know which neibhgour table
>> they are going to look up.
>
> While I understand your intent here, you do really need to know which
> neighbour table being used in order to do the look-up with your new
> function, so this changelog isn't quite accurate. I know Dave has
> already accepted this patch, but it did not appear in the tree I just
> updated, so hopefully there is time to fix this if you agree with me.
Currently __ipv4_lookup_noref and __ipv6_lookup_noref hard code the
table. __neigh_lookup_noref works without needing to hard code the
neighbour table. The neighbour table being a variable in the code and
not a hard coded value is what I was referring to above when I said you
don't need to know your neighbour table. That is you still need a
neighbour table it just doesn't need to be hard coded.
Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists