From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Ahern <dsahern@gmail.com>
Subject: Re: [PATCH net-next 2/7] neighbor: Fold ___neigh_lookup_noref into
 __neigh_lookup_noref
Date: Wed, 5 Dec 2018 17:46:37 -0700
Message-ID: <7ebd3c00-c510-1bd4-34f3-3d6b5f6124ed@gmail.com>
References: <20181205233414.1386-1-dsahern@kernel.org>
 <20181205233414.1386-3-dsahern@kernel.org>
 <20181205.164409.1542545269756488024.davem@davemloft.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: netdev@vger.kernel.org
To: David Miller <davem@davemloft.net>, dsahern@kernel.org
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pl1-f193.google.com ([209.85.214.193]:44676 "EHLO
        mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1727592AbeLFAql (ORCPT
        <rfc822;netdev@vger.kernel.org>); Wed, 5 Dec 2018 19:46:41 -0500
Received: by mail-pl1-f193.google.com with SMTP id k8so10884521pls.11
        for <netdev@vger.kernel.org>; Wed, 05 Dec 2018 16:46:40 -0800 (PST)
In-Reply-To: <20181205.164409.1542545269756488024.davem@davemloft.net>
Content-Language: en-US
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On 12/5/18 5:44 PM, David Miller wrote:
> From: David Ahern <dsahern@kernel.org>
> Date: Wed,  5 Dec 2018 15:34:09 -0800
> 
>> @@ -270,37 +270,25 @@ static inline bool neigh_key_eq128(const struct neighbour *n, const void *pkey)
>>  		(n32[2] ^ p32[2]) | (n32[3] ^ p32[3])) == 0;
>>  }
>>  
>> -static inline struct neighbour *___neigh_lookup_noref(
>> -	struct neigh_table *tbl,
>> -	bool (*key_eq)(const struct neighbour *n, const void *pkey),
>> -	__u32 (*hash)(const void *pkey,
>> -		      const struct net_device *dev,
>> -		      __u32 *hash_rnd),
>> -	const void *pkey,
>> -	struct net_device *dev)
>> +static inline struct neighbour *__neigh_lookup_noref(struct neigh_table *tbl,
>> +						     const void *pkey,
>> +						     struct net_device *dev)
>>  {
> 
> Sorry, we can't do this.
> 
> The whole point of how this is laid out is so that the entire hash traversal,
> including the hash function, is expanded inline.
> 
> This demux is extremely critical on the output side, it must be the
> smallest number of cycles possible.  It was the only way I could justify
> not caching neigh entries in the routes any more when I wrote this code.
> 
> Even before retpoline, putting an indirect call here is painful.  With
> retpoline it is deadly.
> 
> Please avoid removing the full inline expansion of the neigh lookup in the ipv6
> and ipv4 data paths.
> 

ok. patches 5-7 are not dependent on 1-4. Should I re-send outside of
this set?