> The first problem is that the semantics for the in_port in > flow_push_stats() do not match those in xlate_table_action(). In > xlate_table_action(), the resubmitted in_port is used only for the > rule_lookup() and then restored. In flow_push_stats(), the resubmitted > in_port is not restored until flow_push_stats() returns. Maybe this > isn't a real problem, because OFPP_NORMAL and OFPP_IN_PORT do not have > any special semantics in flow_push_stats(), but I do not see a reason > for the difference either. (You could write a helper function > rule_lookup_with_in_port() to encapsulate this lookup.)
In the current implementation both approaches are equivalent. However I'm fine with restoring the in_port similarly to how xlate_table_actions does it as it's probably more future proof. > The second problem is that flow_push_stats() ignores some actions that > will definitely make a difference in behavior, that is, any action that > modifies the flow. Some examples are NXAST_SET_TUNNEL and > NXAST_REG_MOVE. (It's easy enough to find these actions: just > temporarily mark the "flow" member of struct action_xlate_ctx "const" > and recompile and the compiler will point them out for you.) > > I hope that we don't have to duplicate a lot of code to fix the latter > problem. If it becomes a problem I'm sure we can work around it by somehow caching this information when xlate_actions is called. I'll have to put a bit more thought into this. Ethan _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev_openvswitch.org
