Tue, Oct 22, 2013 at 08:15:38AM CEST, [email protected] wrote: >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.
Well, the amount of functions is that high because vast majority of them are setters and getters. I prefer this aproach over direct struct members access in order to have API stable. > >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. > If you would add features supported by teamd already it would definitely take at least 3x that much. And in future, this will go probably even higher. >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. This is thruth in general. Even though, libs continue to exist. > >So, on these grounds, it's hard for me to support a switch away from >internally maintained code to an external library. I understand. Regarding the mantainance of the library, I believe that would be no problem to provide you git access so it is easier to do necessary changes yourself in order to prevent blockage. > >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? Features parity mostly. > >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, [email protected] 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 [email protected] http://openvswitch.org/mailman/listinfo/dev
