On 12/5/18 5:44 PM, David Miller wrote:
> From: David Ahern <dsah...@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?
