[PATCH 1/2] link cache: Add new link api to get link object by family
Roopa Prabhu
roopa at cumulusnetworks.com
Mon Dec 17 10:07:06 EST 2012
On 12/17/12 6:42 AM, Thomas Graf wrote:
> On 12/12/12 at 02:10pm, roopa at cumulusnetworks.com wrote:
>> From: roopa<roopa at cumulusnetworks.com>
>>
>> This patch adds two new api's to get a link object by family:
>>
>> struct rtnl_link *rtnl_link_get_by_family(struct nl_cache *cache,
>> int family, int ifindex)
>> struct rtnl_link *rtnl_link_get_by_family_and_name(struct nl_cache *cache,
>> int family,
>> const char *name)
>>
>> This change comes with the recent addition of AF_BRIDGE support.
>> link cache can now contain objects of more than one family.
>> And the current link get api's only return objects of type AF_UNSPEC.
>> The above new apis will let users query a link object by family.
>>
>> Signed-off-by: Roopa Prabhu<roopa at cumulusnetworks.com>
>
> What about solving this on the cache level instead of adding
> every possible key combination.
>
> Something like:
>
> struct nl_object *nl_cache_find(struct nl_cache *cache,
> struct nl_object *filter);
>
> Unlike nl_cache_search() it would not need a full match but
> would use nl_object_match_filter() and return the first
> object that matches all attributes set.
>
> An additional benefit would be that it could possibly be
> optimized if a hashtable is used.
>
I did think about this. And thought nl_cache_search() is good enough for
these kind of searches (in fact we use nl_cache_search heavily) and the
new api's introduced by this patch were just for symmetry with existing
api's.
Agreed fully though. I do prefer this. I will submit a patch for
nl_cache_find.
thanks!.
More information about the libnl
mailing list