On May 2, 2013, at 21:19 , ext Ben Pfaff wrote: > On Tue, Apr 30, 2013 at 05:21:28AM +0000, Rajahalme, Jarno (NSN - FI/Espoo) > 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. > > I agree (or perhaps if the VLAN has changed) but it seems to me that > it's not hard to add new actions. > > Another approach would be to allow the in_port field to be changed. > Change it to 0 or OFPP_NONE then do your output. Wrap it in > NXAST_STACK_PUSH and NXAST_STACK_POP if you don't want it changed > permanently.
I actually tried changing the "in_port" before realizing it is not writeable. Making it writeable would be one line change. However, setting the in_port for this purpose would add some overhead and maybe seem like a kludge in retrospect, but it might easily become OF compatible, if the "in_port is not writeable" phrase is later removed from the spec. In another mail you said you'd take in a patch to a new action (NXAST_ALLWAYS_OUTPUT?). Which one you prefer? Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev