On Nov 21, 2013, at 1:55 PM, Ben Pfaff <b...@nicira.com> wrote: > On Fri, Nov 15, 2013 at 03:12:18PM -0800, Jarno Rajahalme wrote: >> Allowing the packet to be modified by execution allows less data >> copying for userspace action execution. Some users of the >> dpif_execute already expect that the packet may be modified. This >> patch makes this behavior uniform and makes the userspace datapath and >> the execution helpers modify the packet as it is being executed. >> Userspace action now steals the packet if given permission, as the >> packet is normally not needed after it. The only exception is the >> sample action, and this is accounted for my keeping track of any >> actions that could be following the userspace action. >> >> The packet in dpif_upcall is changed from a pointer to a struct, >> allowing the packet to be honest about it's headroom. After this >> change the packet can safely be pushed on over the precarious 4 byte >> limit earlier allowed by the netlink data preceding the packet. >> >> Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com> > > I'm having a little of a hard time figuring out where to start here. > When you say "allow execute to modify the packet", do you mean the > odp_execute_actions() function specifically? It would be handy to add > a function-level comment to that function so that it becomes clear > what it is allowed to do.
I guess it starts from dpif_execute, and the execute members of each dpif class. Also the dpif execute helpers, and then odp_execute_actions(). I think I added comments to the dpif interface, but it seems I forgot to add a comment to odp_execute_actions(). The packet parameter is no longer a const, though, which should be a subtle hint to the effect that the packet can be modified. Otherwise? Jarno
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
