On Thu, May 01, 2014 at 02:03:05AM -0700, Andy Zhou wrote: > 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?
This seems reasonable to me as a stopgap measure until we can get in the more sophisticated mechanisms. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
