On Fri, May 24, 2013 at 03:54:02PM -0700, Ben Pfaff wrote: > On Thu, May 23, 2013 at 05:15:17PM -0700, Ethan Jackson wrote: > > Before this patch, when in band control was enabled, every DHCP > > packet had to be sent to userspace to calculate it's actions. > > Those DHCP packets intended for the local port would have a special > > action added to ensure they actually make it there. This > > unnecessarily complicates the code, so this patch takes a slightly > > different approach. When in-band is enabled, *all* DHCP packets > > must be sent to the local port. This guarantees that > > xlate_actions() returns the same result every time for a given > > flow. > > > > Signed-off-by: Ethan Jackson <et...@nicira.com> > > This is a nice cleanup. > > Should we renumber SLOW_BFD to 1 << 3, to fill in the gap that > removing SLOW_IN_BAND creates? > > connmgr_may_set_up_flow() is now badly named, because it no longer > affects whether the flow may be set up. > > subfacet_make_actions() was previously used such that it composed its > actions into an on-stack buffer, then made a copy of that buffer into > an exact-sized dynamically allocated buffer. Now, it uses a 0-sized > dynamically allocated buffer. I think this will cause multiple > realloc() calls and generally end up with a bigger dynamically > allocated buffer in the common case.
Another thing: There's still a comment on enum slow_path_reason that mentions SLOW_IN_BAND. Plus, now that all the slow path reasons are mutually exclusive, we could change it from a bitmap to just a number. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
