From: Eric.W.Biederman" <[EMAIL PROTECTED]>"@fr.ibm.com Date: Fri, 21 Dec 2007 14:02:24 +0100
> I'm actually surprised at how much was involved. At first glance it appears > that the neighbour table data structures are already split by network device > so all that should be needed is to modify the user interface commands > to filter the set of neighbours by the network namespace of their devices. > > However a couple things turned up while I was reading through the code. > The proxy neighbour table allows entries with no network device, and > the neighbour parms are per network device (except for the defaults) > so they now need a per network namespace default. > > So I updated the two structures (which surprised me) with their very > own network namespace parameter. Updated the relevant lookup and > destroy routines with a network namespace parameter and modified > the code that interacts with users to filter out neighbour > table entries for devices of other namespaces. > > I'm a little concerned that we can modify and display the global > table configuration and from all network namespaces. But > this appears good enough for now. > > I keep thinking modifying the neighbour table to have per network > namespace instances of each table type would should be cleaner. The > hash table is already dynamically sized so there are it is not a limiter. > The default parameter would be straight forward to take care of. However > when I look at the how the network table is built and used I still find > some assumptions that there is only a single neighbour table for each > type of table in the kernel. The netlink operations, neigh_seq_start, > the non-core network users that call neigh_lookup. So while it might > be doable it would require more refactoring than my current approach > of just doing a little extra filtering in the code. > > Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> > Signed-off-by: Daniel Lezcano <[EMAIL PROTECTED]> Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
