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

Reply via email to