[RFC PATCH 2/5] Add support for updating objects in the cache
Thomas Graf
tgraf at suug.ch
Mon Nov 5 08:56:49 EST 2012
On 11/05/12 at 05:37am, roopa at cumulusnetworks.com wrote:
> From: roopa <roopa at cumulusnetworks.com>
>
> This patch adds support to update a cache object during cache_include instead
> of the current approach of deleting the original object and adding a new one.
> This operation is conditional on the object implementing the operation. If
> the update is not successful, cache_include falls back to the existing cache
> inclusion process of deleting and adding the object.
>
> It adds a new object operation called oo_update. oo_update takes two objects
> as arguments, first being the existing cache object that needs update, the
> second argument being the new object. Currently it is left to the implementor
> to use the msg type to decide wether to delete or add the new object attributes
> to the old one. But the operation type or msg type can be easily made part of the
> object arguments.
>
> The motivation for this change is explained below in the context of including
> support for AF_BRIDGE objects into the link cache.
>
> libnl today deletes an object before it includes an identical object.
> But for some objects like the AF_BRIDGE objects this does not work well.
> link cache uses the ifindex as its key in object searches.
> If link cache were to support AF_BRIDGE family objects, todays implementation,
> - will replace the original link object with the bridge port link object
> for add notifications
> - And a bridge port delete notification from kernel would delete the
> link object from the cache leaving the cache without the link object
> until the kernel sends another notification for that link
>
> The bridge port link notification contains some base link object attributes
> plus bridge specific protocol info attributes. In such cases we think an
> operation to update the existing object in place in cache might be useful.
>
> This can be made to work for AF_INET6 link objects too.
>
>
> Signed-off-by: Roopa Prabhu <roopa at cumulusnetworks.com>
> Reviewed-by: Nolan Leake <nolan at cumulusnetworks.com>
> Reviewed-by: Shrijeet Mukherjee <shm at cumulusnetworks.com>
> Reviewed-by: Wilson Kok <wkok at cumulusnetworks.com>
Applied, thanks Roopa!
More information about the libnl
mailing list