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

Thomas Graf tgraf at suug.ch
Mon Nov 5 11:06:58 EST 2012


On 11/05/12 at 07:58am, Roopa Prabhu wrote:
> Oh ..ok. This summary helps. So if I understand correctly, we will
> use the same cache, and update bridge data into existing link
> objects.

Exactly. To me this is the cleanest option and the most transparent
option to the user.

> And problems during refills will be taken care of by the new cache
> manager api you proposed and ITER flag.

If link_msg_parser() manages to merge the additional AF_BRIDGE object
information into the existing link objects we can enable the ITER
flag on link caches by default and thus make the bridging information
available in default link caches.

So a link_cache_refill() on a link cache would use a AF_UNSPEC and a
AF_BRIDGE dump to populate the cache contents.

Sames goes for the cache manager. We could pick up bridging
information and merge into existing link cache objects on the fly.

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

OK, sounds good.



More information about the libnl mailing list