Re: [mpls-linux-devel] neigh_table_find removed in 2.6.2
Status: Beta
Brought to you by:
jleu
From: James R. L. <jl...@mi...> - 2004-02-06 16:28:16
|
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... |