On Jun 29, 2013, at 1:05 , ext Jesse Gross wrote: > On Tue, Jun 25, 2013 at 1:08 AM, Rajahalme, Jarno (NSN - FI/Espoo) > <jarno.rajaha...@nsn.com> wrote: >> 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. > > I would want to see some pretty compelling numbers on this before > proceeding down this path. For example, I don't think that the cost of > facet revalidation should be a factor here since you could keep a > group indirection table in userspace and swap out the appropriate > ports without recomputing the full action list from scratch. This > might be complicated when you have complex sets and types of groups > but to me that's an argument for doing it in userspace, since there is > more information and flexibility there.
I guess an ofproto-dpif -level implementation will be needed first, then :-) Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
