[ovs-dev] [tags 3/3] tag: Retire the venerable tag library.

Ben Pfaff blp at nicira.com
Fri Aug 2 17:45:37 UTC 2013


On Thu, Aug 01, 2013 at 07:08:34PM -0700, Ethan Jackson wrote:
> This patch retires a venerable library whose inception dates before
> the first patch of the current repository: tags.  They have served us
> well, but their time has come for the reasons listed below.
> 
> 1) They don't actually help much.
> In theory, tags had been used to reduce revalidation necessary when
> using bonds, mac-learning, and frequently changing flow tables.  With
> bonds and mac-learning, things change happen so rarely that tagging
> isn't worth it.  That leaves flow table changes. With the complex flow
> tables in my testing, the revalidate_set gets so overwhelmed with
> tags, that we end up revalidating every facet every time through the
> run loop.  In other words, they tags are giving us no benefit.
> 
> 2) They complicate the code.
> This patch simplifies the code and removes a couple of rather ugly
> kludges.
> 
> 3) They complicated locking once threading hits.
> Because of the calculate_flow_tag() function, the table_dpif structure
> would require locking in a multi-threaded OVS.  Though this problem
> isn't insurmountable, it's annoying and probably would cause lock
> contention.
> 
> Of course, we could try to work around these problems with a more
> advanced tagging infrastructure, but this moves in the opposite of the
> direction we should be.  Ideally we'll have a more-or-less stateless
> ofproto-dpif supporting a massive number of datapath flows.  Tags (or
> facets for that matter) aren't going to work in this new world.
> 
> Signed-off-by: Ethan Jackson <ethan at nicira.com>

I think that we should keep ofoperation_get_victim() and the related
comment in ofproto_class, because it seems completely reasonable that
some ofproto implementation would need this information.  I am surprised
that ofproto-dpif no longer needs it.

Otherwise:
Acked-by: Ben Pfaff <blp at nicira.com>



More information about the dev mailing list