> On Wed, Apr 30, 2014 at 11:59 PM, YAMAMOTO Takashi > <yamam...@valinux.co.jp> wrote: >>>> Something like this (I have not tested either scenario): >>>> >>>> I think this will fail to match but that may not be obvious to users: >>>> packet_out: in_port=CONTROLLER actions=goto_table:1 >>>> table 1: match=in_port=CONTROLLER actions=normal >>>> >>>> I think this will match but that may not be obvious to users: >>>> packet_out: in_port=CONTROLLER actions=goto_table:1 >>>> table 1: match=in_port=LOCAL actions=normal >>>> >>>> Where CONTROLLER could be any port covered by this patch. >>>> >>> Only ODP ports are changed to LOCAL, so simple rule matches as >>> outlined should work. >>> However, this scenario is valid when recirculation is involved. I am >>> not sure what we should >>> do about this edge case either. >> >> how about having a userspace-only special variant of RECIRC action, >> which can specify in_port as (ofproto, ofp port) and thus can be >> used even when odp port is not available? >> >> if a translation detects the condition (ie. recirculation is necessary >> but in_port does not have the corresponding odp port), it can use >> the userspace variant with SLOW_ACTION instead of normal RECIRC. > > Not all actions can be executed in the user space. Hash action can > only be executed > in datapath. User space, by design, can not predict the hash value > computed by the > datapath.
then HASH action ought to be handle specially. (like OUTPUT?) the current code seems broken in that regard. if some SLOW_ACTIONs are involved, the upcall hander would use DPIF_OP_EXECUTE with needs_help=true, which ends up with dpif_execute_with_help, to execute actions, which might include HASH and RECIRC. but dpif_execute_helper_cb can't handle these actions. ie. OVS_NOT_REACHED in dpif_execute_helper_cb seems actually reachable. YAMAMOTO Takashi >> >> YAMAMOTO Takashi > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev