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