On Tue, Jul 14, 2015 at 12:40 PM, Ben Pfaff <b...@nicira.com> wrote: > On Tue, Jul 07, 2015 at 10:30:05PM -0700, Jesse Gross wrote: > Here's a comment for struct tun_metadata with a little more detail, to > try to make sure I understand it correctly: > > /* Tunnel option data, plus metadata to aid in their interpretation. > * > * Option data exists in two forms. Most of the time, the code path we're in > * determines which form is in use; in the occasional case where there is > * ambiguity, code can distinguish based on whether 'tab' is nonnull. The [...] > Do we need 'udpif_no_xlate'? That is, can odp_flow_key_from_flow() > check whether flow->tun.metadata.tab != NULL to distinguish the cases?
Unfortunately, it's not true that 'tab' being non-NULL is enough to distinguish between the two cases. The raw form (the one introduced in this patch) will always have tab equal to NULL. However, in the original form, 'tab' may or may not be set - it is set for incoming flows going through upcall processing but not for matches/actions that need to stick around for a longer period of time (those need to refetch the global pointer since they can't use RCU). I decided that a better approach is to use one of the tunnel flags to indicate which format things are in, which is cleaner, safer and also opens up the door to use this mechanism for other purposes as well. I incorporated the other comments and sent out a new version of this series. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
