mpls_tunnel_list was used to keep a small list of MPLS tunnels, so
removes and lookups would be faster. With the new "support for large
number of interfaces" code being added to 2.6.3, I think the value of
keeping this small list is minimal.
On Sun, Feb 08, 2004 at 09:04:06AM +0100, Ramon Casellas wrote:
>
>
> Hi,
>
> I've been thinking about this, and I don't see why do we need to
> keep a separate list of mpls tunnels. Assume we remove it
>
> Disadvantages:
>
> * To identify the list of mpls tunnels we need to check private flags
> and/or if (dev->type == ARPHRD_MPLS_TUNNEL). We only need to do this from
> process context, and, unless the user has hundreds of network devices,
> overhead is small.
>
>
> Advantages:
>
> * The functions: mpls-tunnel_init mpls_tunnel_link mpls_tunnel_unlink
> can be removed.
>
> * We avoid synchronization issues with rtnl_lock and list lock, and we
> avoid incoherences between the main dev_base list and our private list.
>
> * Avoid race conditions when removing the module.
>
> * Code is cleaner and easier to understand.
>
> Comments? I am all for a removal...
>
> R.
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel
--
James R. Leu
jl...@mi...
|
