I'm working on an implementation of forwarding groups based on the master branch of OvS. I'm hoping to upstream this code, so I want to do it in a sensible way.
I appreciate how the new 'ofpact' structures isolate the datapath from the Openflow wire protocol, but they pose a design question for the implementation of group action buckets, so I'd like to get some feedback before I go much further. All the actions for a given flow are internally represented (and passed over the ofproto_provider API) in a single flat buffer containing 'ofpact' structures. So in my first attempt, I tried to emulate this approach by interleaving a new 'ofpbucket' structure along with the ofpacts into a single buffer representing all the buckets for a given group. (A given group's representation includes a buffer with an ofpbucket structure, followed by 'ofpbucket.len' bytes of ofpact structures, followed by another ofpbucket structure, and so on.) This approach resulted in a lot of weirdness and rebuffering because, in some places (like 'str_to_ofpacts'), the existing code assumes that an ofpbuf contains *only* ofpacts. Structure padding also complicates things. The other option I'm considering is to represent a group with a variable-length array of fixed-length ofpbucket structs, each of which points to a *separate* buffer containing that bucket's ofpacts. This would require more/smaller buffers and thus incur more memory management overhead, but I think it might be more maintainable. I'm now leaning towards the second option, but I haven't fully absorbed the design of the ofpact management yet, so I don't know if I'd be making a terrible mistake or violating some assumption. Was there compelling reason to collect the ofpacts in a single buffer (vs., say, an array of pointers) that would also apply to the group buckets? Any other thoughts or concerns? Casey Barker
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
