On Thu, May 2, 2013 at 12:59 AM, Rajahalme, Jarno (NSN - FI/Espoo) <jarno.rajaha...@nsn.com> wrote: > > On Apr 30, 2013, at 18:54 , ext Jesse Gross wrote: > >> On Mon, Apr 29, 2013 at 10:21 PM, Rajahalme, Jarno (NSN - FI/Espoo) >> <jarno.rajaha...@nsn.com> wrote: >>> >>> On Apr 29, 2013, at 20:49 , ext Jesse Gross wrote: >>> >>>> On Sun, Apr 28, 2013 at 11:29 AM, Rajahalme, Jarno (NSN - FI/Espoo) >>>> <jarno.rajaha...@nsn.com> wrote: >>>>> >>>>> Another thing that I came to think only when reading Ben's new tutorial: >>>>> Output to the input port is skipped. This would be a problem if you only >>>>> have one generic flow based GRE port (as enabled by the last patch in >>>>> this series), and you should forward GRE input to another GRE output. >>>>> This could be fixed by always allowing output (in xlate_output_action()) >>>>> to a tunnel that has cfg.ip_dst_flow set, even if the output port is the >>>>> same as the input port. Thoughts? >>>> >>>> I know that Ben was thinking about ways to relax this check anyways, >>>> so it might be good to see how that fits with this. >>> >>> >>> It seems to me that it should be relatively safe to allow packets that have >>> been modified by actions to be sent to the input port, if so directed by the >>> flow action. At least when the destination mac has been changed. >> >> The concern that Ben had was that this changes OpenFlow semantics and >> that will lead to confusion over time. You coud make a similar >> argument about vlans: performing a vlan action should disable the >> loopback check. However, that is not what the spec says. > > Maybe the cleanest way forward would be a new bit in ofp_port.config to allow > output on incoming port (maybe for modified packets only). This would need to > be set by the controller for any ports it wants to behave like this, > therefore no > confusion. Obviously this would be an extension to the current spec.
I think the approach that Ben was considering is to introduce a special output action that would not have this restriction. That way the semantics would be very clear. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
