Thanks you for clarifying the need. Since there is no urgent need to introduce a stop gap measure, I am happy to drop this patch for now.
On Thu, May 1, 2014 at 10:10 PM, Simon Horman <si...@horms.net> wrote: > 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
