On Thu, May 1, 2014 at 1:20 AM, Simon Horman <si...@horms.net> wrote: > On Thu, May 01, 2014 at 03:59:20PM +0900, YAMAMOTO Takashi 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 completely agree with that analysis. > >> > 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. > > FWIW I am happy with either that approach (assuming it works) > or Andy's approach. But I lean towards the simplicity of Andy's approach.
It seems we are missing some infrastructure to handle those edge case properly: 1. Datapath, currently, requires a valid datapath in_port to packets. 2. Patch ports and CONTROLLER do not have corresponding datapath ports. With those limitations, when datapath makes an upcall, user space can not recover the original ofport. This limitation actually goes beyond PACKET_OUT. To properly solve it, we will need some infrastructure to allow user space to recover the original ofport, either by passing it to the datapath, or by some other means to re-associate them within the user space. This infrastructure change is more complex and general than the problem at hand. I think we should improve the packet_out handling for now, assuming Simon's work can benefit from such improvement. If we decide to go down this road, we should note the limitations so that we can revisit them when proper infrastructure are in place. Make sense? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
