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 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. Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
