On Tue, Jun 25, 2013 at 08:08:08AM +0000, Rajahalme, Jarno (NSN - FI/Espoo) wrote: > > On Jun 25, 2013, at 1:22 , ext Ben Pfaff wrote: > > > What I really want to do is reconcile the two patch series, so that we > > can get the best features from both. Your code is always solid in my > > experience, so I'm kind of inclined to just review yours and apply it, > > and then go through the Centec code and find its strengths and try to > > take advantage of them. One place this is likely to be the case is in > > the ofproto_provider interface, because the Centec implementation > > actually takes advantage of ASIC hardware, which means that the > > provider interface there is known to work for that purpose. > > I feel the current OVS architecture is more demanding on the meter > ofproto_provider interface than an ASIC provider might be. There are > multiple datapath implementations, each of which can be used to > support multiple ofproto instances. I think it would be wise to keep > the design rather open until we have implementations for all the > datapaths, including the linux kernel datapath.
I always keep a design open (until I'm stuck with a frozen ABI). We've rewritten major parts of OVS many times before, and it'll happen again. I haven't read either patch in detail yet. > I also tried to figure out how the group table should be > implemented. I haven't done anything for it yet, but I'm rather > convinced that the datapath should maintain the group table so that > there would be no need for facet revalidation when group table > entries change. The alternative of translating the group actions to > the facet action lists would result in rather expensive facet > revalidations whenever there is a change in the group tables. This > is made even more complex by groups within groups, etc. However, if > the datapath maintains the group table separately from the flow > table, changes to the group tables would be very cheap due to the > indirection provided: if an existing entry in the group table > changes, the flow action referring to that group will find the > updated entry for the very next packet being processed without any > facet revalidations. This would make, e.g., some route table updates > very efficient. At least one iteration of the kernel datapath supported a feature like this. I don't remember the name (maybe they were in fact "groups", this was built pre-OF1.1), but flow actions could execute what were essentially macros that expanded at flow execution time to whatever was stored there at the time. We only used it for "flood" and "all" actions at the time, so we didn't consider it useful enough to carry it forward to the current kernel datapath. But we could always add such a feature back if it would be useful. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
