Hi Kuniyuki,

This introduces O(n) list traversal while it can be done
with fixed costs (3 dereferences + 1 call).

Since neigh_table is global (arp_tbl or nd_tbl), the O(n)
list traversal could take longer and rather de-optimise.

Yes, that is true. One reason why I chose to do that is
because ndo_neigh_setup is a function primarily meant 
to setup the neigh_parms structure, when neigh_parms does
not exist.
On the other hand, lookup_neigh_parms is meant
to search for a near-complete neigh_parms structure,
that is already associated with a netdev. 
Even if we want to use ndo_neigh_setup, since it takes
less time, I would suggest using it as a fallback to 
not finding an already existing parms, setup.

Moreover, time complexity might not be an issue in this
path since, this is rarely used aggresively. 


One issue with ndo_neigh_setup in bond-like devices is
that, to get the underlying netdevs neigh_setup function,
it expects us to pass a dummy neigh_parms structure that 
has been zeroed out. This seems to be fragile as suggested
in a TODO in bond_neigh_init(). 
Generally its main goal is to fill the parms.neigh_setup 
field.

Can we populate a few more fields in the zeroed-
out parms structure, before passing to the driver in 
ndo_neigh_setup? That seems to be a much safer approach.

Regards,
Paritosh