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

[Roopa Prabhu]

On 11/5/12 7:20 AM, Thomas Graf wrote:
> 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?

Oh ..ok. This summary helps. So if I understand correctly, we will use 
the same cache, and update bridge data into existing link objects.
And problems during refills will be taken care of by the new cache 
manager api you proposed and ITER flag.

yes this sounds good. Let me respin the patch and in the process I will
make sure everything is covered.

Thanks!.