Re: [mpls-linux-devel] neigh_table_find removed in 2.6.2

[James R. L. <jl...@mi...>]

I agree that the current use of the neighbour table without holding
some sort of refcount is "a bad thing" and should be fixed.  I will look
into this tonight.

On Fri, Feb 06, 2004 at 05:17:30PM +0100, Ramon Casellas wrote:
> On Fri, 6 Feb 2004, James R. Leu wrote:
> 
> > 
> > The current use of IPv[4|6] neighbour tables already caches the DA, SA, and
> > MPLS ethertype. Look at the debug output for mpls_send().  It shows
> > that it is using the hh cache, and the resulting packet has the correct
> > ethertype.
> 
> 
> Right, right, I know, the hh_type is set when the neighbour is being 
> initialized, and from the type in the dst ops protocol (which is MPLS).
> (and since we override the dst, thinks work fine).
> 
> This is not necessarily wrong, but my point is that we do not have an 
> homogeneous neighbour-hh_object with a single address family (and I 
> don't know if we should)... I was just thinking vaguely about the 
> possibility of doing like in DECnet of IPv6, where they do manage their 
> own set of neighbours and a neighbour table. 
> 
> Maybe we should, if later we want to transport other payloads, we should
> have a uniform view of *neighbour LSRs* for AF_MPLS (within the scope of a
> well defined Layer 2 technology, agnostic to the layer 3 protocol). The L3 
> details are left for mpls_dsts.
> 
> Well, that's just Food for thoughts for MPLs-Linux 3.0 :), but my issue 
> about not increasing the refcount of the neighbour table (although a rare 
> event) applies
> 
> thanks for reading...
> 

-- 
James R. Leu
jl...@mi...