Ok Harald, I did some snooping around and here is what
I've come up with.
1) We have 5 or 6 implementations of "walk neighbour hash
table in sequence", that's rediculious and is the only
reason that hashtable layout or number of entries is
even known by code outside of net/core/neighbour.c
In fact, many cases get it wrong :( For example, the
ARP seq_file stuff locks the normal hash table correctly
but does zero locking when traversing the pneigh hashes.
Oops. Another reason to put this logic in a common spot.
So I think the first thing to do is to write table
walker functions generically inside of net/core/neighbour.c
This is the first step.
1.5) tbl->ops->hash() should return the raw hash, the caller
will do the necessary masking.
At this point, there is no reason to declare
{P,}NEIGH_HASHMASK in net/neighbour.h
2) We should size these hash table dynamically, growing them
at neigh_create() time.
This makes the most sense, and the scheme is similar to how
net/ipv4/fib_hash.c works, for example.
3) If we have a sysctl for this stuff at all, it will be for
the limit of the hash table growth, but I don't think that
is necessary given #2
I like the jenkins hash change and yes I think it should be applied
elsewhere too.
I'll work on the set of patches implementing the above tomorrow
and will send it to the list for review and commentary.
|