On Sat, Jan 02, 2016 at 11:16:57PM -0800, Ben Warren wrote:
>
> > On Jan 2, 2016, at 6:27 PM, Ben Pfaff <b...@ovn.org> wrote:
> >
> > On Thu, Dec 31, 2015 at 03:24:52PM -0800, Ben Warren wrote:
> >> We use Go as our system programming language, and interact extensively
> >> with ovs-vswitchd. Since we’re also keen on the latest things going
> >> into Openvswitch (currently using conntrack and looking forward to
> >> NAT), a vanilla Openflow client isn’t very useful - we really need
> >> something like ovs-ofctl that handles all the extensions. I’ve been
> >> playing around with writing a Go wrapper for libopenvswitch.so and
> >> takes advantage of all the wonderful parsing and serdes functions that
> >> the OVS team has written. I have it working well, but there’s a lot
> >> of hackery around getting header files in the right places. We’re
> >> also a Debian shop, and I’d really like to be able to distribute the
> >> shared libraries and header files in the vein of libfoo-dev packages.
> >>
> >> I’m happy to do the leg work to make this happen, but would like some
> >> guidance on how the files should be organized. I see that there are
> >> already rules for assembling the “include/openvswitch” and
> >> “include/openflow” headers, but not the core ones in “lib” that I
> >> need. I found some discussion on the mailing list from when the
> >> “—enable-shared” configure option was added, mainly about API
> >> versioning etc, so it seems that mine isn’t a new idea, and there are
> >> probably others that would benefit.
> >
> > Most of the Open vSwitch libraries aren't well organized for use by
> > outside software. We're probably overdue to fix that, but so far little
> > effort has been put into it.
> >
> > There's a couple of approaches we could take here. One is to start
> > working toward making the most important OVS libraries more friendly for
> > use by outside software. That would probably involve moving headers
> > from lib/ to include/openvswitch while considering whether their names
> > and interfaces were appropriate. Another approach would be to just
> > semi-officially sanction some nasty hacks and push off doing it
> > "correctly" into the indefinite future. Though I'd prefer the first
> > approach, the second might be OK if it doesn't prevent doing it
> > correctly in future versions.
> >
> I’ll start down the path of doing the right thing, and will only veer
> off into hack land if absolutely necessary. Moving files around and
> making sure things compile is easy - refactoring interfaces will
> require a lot more context and knowledge of the code base. Another
> big caveat is that I’m only able to build and test the parts that we
> use. Hopefully others can make up the difference.
>
> > What APIs in particular are you thinking about?
>
> I’ll get the biggest bang out of programmatically implementing
> ‘ovs-ofctl’. The first order of business is to parse flow information
> using ‘parse_ofp_flow_mod_str()’ and ‘ofputil_encode_flow_mod()’, then
> send it on the wire using a socket that my code manages. I can see
> how these might be simplified when thinking about external-facing
> interfaces into a single function that takes a string a returns
> something close to a raw buffer, but understand that it will take time
> and iteration to get this right.
That's some of the most intricate protocol-handling code around! But
that's also the reason it's valuable to third-party software, I suppose.
I guess there are three main issues here:
1. Namespace. OVS doesn't consistently prefix its identifiers, so
it invades third-party namespace in numerous places.
2. API and ABI stability. There basically isn't any from one OVS
version to another, because until now we would update all clients
whenever an interface changed.
3. (less important) Performance. Adding an indirection through the
GOT/PLT and losing a register slows stuff down (less on x86-64
than previously on i386 though).
We can work on all of these over time.
Anyone who hasn't read
https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf
should probably read it now.
I'll look forward to patches. I recommend sending small series of
patches as you become happy with them, especially at first while we're
working on figuring out a pattern here.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
