[ovs-dev] [PATCH] Skeleton for midokura extensions.

Ben Pfaff blp at nicira.com
Sat Aug 6 00:04:07 UTC 2011


On Thu, Aug 04, 2011 at 06:55:45AM +0900, Simon Horman wrote:
> On Wed, Aug 03, 2011 at 02:04:09PM -0700, Ben Pfaff wrote:
> > [Adding patch author as CC.]
> > 
> > On Wed, Aug 03, 2011 at 04:04:11PM +0900, Simon Horman wrote:
> > > I believe that there is some discussion to be had on if some sort of API
> > > should be provided to allow vendors to register their own extensions (e.g.
> > > at compile time). But as there is currently no such API I would like this
> > > patch considered for merging.
> > 
> > I'd rather actually talk about what that "API" should look like.
> > Ideally we'd be able to also implement at least some of the Nicira
> > extensions using the same compile-time method, which would mean that
> > we wouldn't accidentally break it.
> > 
> > Do you have an initial proposal?
> 
> To be honest I haven't thought about what the API would look like in
> detail. But I had got as far as thinking in terms of register
> and unregister functions which take a structure which describes
> a list of types which are in turn structures that describe a list
> of subtypes.
> 
> Beyond that, I imagine that the portions of existing case statements that
> handle extensions would need to be replaced by loops that search
> through registered types or subtypes.
> 
> I guess that this wouldn't be particularly efficient. But assuming
> that there is a reasonable small number of extensions it seems that
> it ought to be fast enough.

This sounds to me like a runtime API instead of a compile-time one.  I
was thinking more of a way to make it easier and more reliable to
patch more actions into the tree.

I sent out a patch earlier today that makes it harder to get it wrong
when adding new actions:
	http://openvswitch.org/pipermail/dev/2011-August/010295.html

It looks like the Midokura action header has the subtype in the same
place as the Nicira action header.  If that's so then it would be
pretty easy to extend what I wrote to add more vendors.



More information about the dev mailing list