[PATCH 1/3] Add support for per cache flags

Roopa Prabhu roopa at cumulusnetworks.com
Mon Nov 12 09:41:04 EST 2012


On 11/12/12 6:30 AM, Thomas Graf wrote:
> On 11/12/12 at 06:15am, Roopa Prabhu wrote:
>>> Use Case 2: (Change setting of an individual cache)
>>>          struct nl_cache *link_cache;
>>>
>>>          link_cache = rtnl_link_alloc_cache([...]);
>> Am guessing you meant nl_alloc_cache here
>
> rtnl_link_alloc_cache() is just a shortcut for nl_alloc_cache()
> of type route/link followed by a refill. By allowing to modify
> the ops and then derive the cache flags from it we add support
> for AF_ITER to the existing API functions.
>

ok yes it can be used that way. But my only concern there was that it
results in refill twice. Once in rtnl_link_alloc_cache and the other
in nl_cache_mngr_add_cache.



>>> 	nl_cache_set_flags(link_cache, NL_CACHE_AFTER_ITER);
>>
>> And NL_CACHE_AF_ITER here
>
> yes
>
>>> 	nl_cache_mngr_add_cache([...], link_cache);
>>>
>>> i.e. add a new c_flags to struct nl_cache and inherit its value
>> >from ops->co_flags and always use cache->c_flags when checking
>>> whether the feature is enabled.
>>
>> ok I will respin. Just so i am clear,
>>
>> void nl_cache_ops_set_flags(struct nl_cache_ops *ops, unsigned int flags)
>> {
>>          ops->co_flags |= flags	
>> }
>>
>>
>> void nl_cache_set_flags(struct nl_cache *cache, unsigned int flags)
>> {
>>
>>          cache->c_flags |= flags;
>> }
>>
>> And in alloc cache cache->c_flags |= ops->co_flags
>> plus use cache->c_flags in fill and resync
>
> Exactly.
>
> _______________________________________________
> libnl mailing list
> libnl at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libnl




More information about the libnl mailing list