[RFC PATCH 4/5] Add support for a new bridge link cache route/bridge_link

Thomas Graf tgraf at suug.ch
Mon Nov 5 10:20:22 EST 2012


On 11/05/12 at 05:37am, roopa at cumulusnetworks.com wrote:
> From: roopa <roopa at cumulusnetworks.com>
> 
> This patch adds support for a new rtnl cache ('route/bridge_link')
> for bridge port link cache management. The kernel bridge code uses
> RTM_NEWLINK and RTM_DELLINK with family AF_BRIDGE to notify
> bridge port addition/deletion.
> 
> This patch adds new rtnl bridge link cache ops rtnl_bridge_link_ops
> and bridge link object ops bridge_link_obj_ops respectively. This cache
> is similar to the link cache but tailored to the AF_BRIDGE link
> operations. At any point this cache will only contain link
> objects associated with a bridge.
> 
> Note: Since the bridge link cache code is almost similar to link cache,
> eventually bridge link cache can be made to use the link cache object
> ops ie rtnl_link_object_ops to avoid some code duplication. Its not already
> done that way in the current patch because it seems to conflict with
> NL_AUTO_PROVIDE. With NL_AUTO_PROVIDE, the caller of
> nl_cache_mngt_require('route/bridge_link)' could get 'route/link' in return,
> since they share the same object type. (This needs further thought)

Reusing the code is definitely desirable. I don't want to duplicate
all of this code.

We already have code in place to allow specyfing the address family
and thus limit a link cache to bridges only:

	rtnl_link_alloc_cache(sk, AF_BRIDGE, &cache);

so what we really need is to have link_msg_parser() be capable of
handling AF_BRIDGE RTM_NEWLINK messages. How about we merge the
bridging information into the existing link objects and hide all
the complexity from the user?

Summarizing we want:

 * the behaviour to stay as-is for existing code

 * setting NL_CACHE_AF_ITER flag allows to keep both link and
   briding links in the same cache

 * for the following to automatically keep a sync'ed list of
   bridges:

	rtnl_link_alloc_cache(sk, AF_BRIDGE, &cache);
	nl_cache_mngr_add_cache(mngr, cache, [...]);

 * for the following to contain a list of all links ...
	rtnl_link_alloc_cache(sk, AF_UNSPEC, &cache);
	nl_cache_mngr_add_cache(mngr, cache, [...]);

   ... but no dupliactes for bridges. The additional bridging
       info should be merged into bridge.c so it can be
       retrieved using a rtnl_link_bridge_get_*() API

How does that sound?



More information about the libnl mailing list