On Thu, May 01, 2014 at 07:46:21AM -0700, Ben Pfaff wrote: > 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.
I would be happy to do without this stopgap measure if (a rebased version of) the recirculation MPLS would be considered with the caveat that packets with an in_port that doesn't exist in the datapath can't be recirculated (yet). I believe that this is reasonable as it is already the case for recirculation for bonding. And as Andy pointed out, the problem is deeper than the specific cases that started this thread. The reason I propose doing without the stopgap measure is that it (by virtue of its design) changes the in port of packets and that may effect behaviour: such as that discussed above. And if the stopgap is subsequently no longer needed it will be awkward to either support or drop that behaviour. The reason that I originally proposed fixing this problem was that I have some tests that exercise it. In particular tests provided by Ryu. But I can still use those tests to exercise my recirculation for MPLS code by simply using the stopgap measure locally. And I have other tests to exercise recirculation for MPLS which do not run into the in_port problem and thus can be used without needing the stopgap measure at all. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
