From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Gospodarek Subject: Re: [PATCH net-next 1/2] neigh: Factor out ___neigh_lookup_noref Date: Wed, 4 Mar 2015 11:30:53 -0500 Message-ID: <20150304163053.GC1551@gospo> References: <874mq22imc.fsf_-_@x220.int.ebiederm.org> <20150303.144509.1694022322984204895.davem@davemloft.net> <87mw3tzv8u.fsf@x220.int.ebiederm.org> <20150303.153310.624302583835136622.davem@davemloft.net> <87h9u1y8y8.fsf_-_@x220.int.ebiederm.org> <87bnk9y8wb.fsf_-_@x220.int.ebiederm.org> <20150304145331.GA1551@gospo> <87sidkoiu3.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Miller , netdev@vger.kernel.org To: "Eric W. Biederman" Return-path: Received: from mail-qg0-f42.google.com ([209.85.192.42]:36357 "EHLO mail-qg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758856AbbCDQax (ORCPT ); Wed, 4 Mar 2015 11:30:53 -0500 Received: by qgdz107 with SMTP id z107so431468qgd.3 for ; Wed, 04 Mar 2015 08:30:53 -0800 (PST) Content-Disposition: inline In-Reply-To: <87sidkoiu3.fsf@x220.int.ebiederm.org> Sender: netdev-owner@vger.kernel.org List-ID: On Wed, Mar 04, 2015 at 09:58:28AM -0600, Eric W. Biederman wrote: > Andy Gospodarek 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. Thanks for the clarification.