Hi Jiri. Sorry about the delay in responding. I've been taking my time to mull the various issues that came up as I thought about it.
When you suggested this off-list, my first thought was that this could be beneficial to all parties. After all, avoiding code duplication means that there is less code to write overall, and thus less work to do. I think that we could all stand to do less work. Thanks for taking the time to write up such a detailed API. I found it revealing, especially of the amount of complication required in the API. By my count, the API has over 80 functions in it, which seems like a lot (entire early Unixes had far fewer system calls than that!). I'm really quite worried about stabilizing such an API and making it usable for both (all?) of its users. That wouldn't be a big deal if the library solved a thorny problem or required a lot of code or was difficult to maintain. Good examples of libraries in those categories are OpenSSL (which OVS uses) and liburcu (which OVS may use in a version or two; we are considering it). But, if you look at the code in OVS corresponding to the proposed liblagg, in lib/lacp.c and lib/bond.c, it's only about 2400 lines of code, and none of it is particularly complicated or hard to maintain. The code in lib/lacp.c and lib/bond.c does continue changing, but that's mainly to adapt to new OVS internal needs, e.g. the "megaflows" change in OVS 1.11 and threading in OVS 2.0. That brings up the question of evolution. It's easy to update the internal versions of code as OVS itself evolves, but it would be much more difficult to update an external library. So, on these grounds, it's hard for me to support a switch away from internally maintained code to an external library. One factor I don't know about, however, is which features are supported by teamd and not by OVS. Were you considering those features on just the basis of feature parity, or because some user particularly wanted those features in OVS, or on some other basis? Thanks, Ben. On Fri, Oct 18, 2013 at 09:54:02AM +0200, Jiri Pirko wrote: > Hi, Any thoughts on this subject? > > Thanks > > Jiri > > Tue, Oct 08, 2013 at 04:06:23PM CEST, j...@resnulli.us wrote: > >Hi OVS developers. > > > >I'm a maintainer of Team driver and libteam (userspace counterpart). > > > >Recently I have been looking into ovs userspace and kernel code wrt > >bonding features. Looks like there is a room to add a features which are > >currently already supported by teamd. > > > >Here's what I have on mind: Push out common link aggregation logic from > >teamd into a library (liblagg). After that, ovs can use this library as > >well. Another benefit is that we would have a single code to maintain > >for all link aggregation logic. > > > >Here is a draft of API: > >http://resnulli.us/lagg.h > > > >liblagg would be probably sicenced under dual LGPL2+ + BSD or dual LGPL2+ + > >Apache 2.0 > > > >What do you think? > > > >Regards, > > Jiri > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
