[PATCH 0/19] Disconnect neigh from dst_entry

[PATCH 0/19] Disconnect neigh from dst_entry

[David Miller]

This finally severs neighbour table entries from dst_entry enough that
we no longer depend upon them outside of the individual protocols.

Besides being a major step towards making routing cache removal
practical, it also means an end to the infamous "neighbour table
overflow" condition.

Routes in ipv4 no longer refer to neighbour table entries, they are
used on an as-needed basis during packet output in a refcount-less
manner.

Therefore garbage collection is trivial since almost nothing actually
holds onto neighbour table references.

On the routing cache removal side, this set of changes removes another
dependency upon rt->rt_dst.  The only one left is for inetpeer, and
once that is severed (I have a rough plan for it) rt->rt_dst is finally
without any use and we can construct ipv4 routes directly inside of
FIB table entries.

Signed-off-by: David S. Miller <davem@davemloft.net>

Re: [PATCH 0/19] Disconnect neigh from dst_entry

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Tue, 03 Jul 2012 02:45:43 -0700 (PDT)

> This finally severs neighbour table entries from dst_entry enough that
> we no longer depend upon them outside of the individual protocols.

I'm pushing this now to net-next, with three minor changes.

1) I fubar'd the neigh lookup in the sch_teql changes, I needed to
   add the following code block to __teql_resolve():

       if (dst->dev != dev) {
                struct neighbour *mn;

                mn = __neigh_lookup_errno(n->tbl, n->primary_key, dev);
                neigh_release(n);
                if (IS_ERR(mn))
                        return PTR_ERR(mn);
                n = mn;
        }

2) I adjusted the comment in the neigh backlog handler of
   neigh_update() to read as follows:


	/* Why not just use 'neigh' as-is?  The problem is that
	 * things such as shaper, eql, and sch_teql can end up
	 * using alternative, different, neigh objects to output
	 * the packet in the output path.  So what we need to do
	 * here is re-lookup the top-level neigh in the path so
	 * we can reinject the packet there.
	 */

3) The redirect network event needs to also pass in the path
   destination address so that we can have it available for
   all callers of t3_l2t_get().