On Fri, Jan 20, 2017 at 3:33 PM, Ben Pfaff <[email protected]> wrote:

> On Fri, Jan 20, 2017 at 03:17:19PM -0800, Mickey Spiegel wrote:
> > On Fri, Jan 20, 2017 at 2:43 PM, Ben Pfaff <[email protected]> wrote:
> >
> > > On Fri, Jan 20, 2017 at 12:29:49PM -0800, Mickey Spiegel wrote:
> > > > On Fri, Jan 20, 2017 at 9:16 AM, Ben Pfaff <[email protected]> wrote:
> > > >
> > > > > I believe that, with these patches, egress loopback as proposed by
> > > Mickey's
> > > > > patches can be implemented with:
> > > > >     clone { inport = outport; outport = ""; flags.loopback = 0;
> > > > >             reg0 = 0; reg1 = 0; ... regN = 0;
> > > > >             next(pipeline=ingress, table=0); }
> > > > >
> > > >
> > > > My main concern is maintainability as new flags or registers are
> added.
> > > > Having one line of code buried deep inside ovn/northd/ovn-northd.c
> that
> > > > needs to be updated whenever a flag or register is added worries me.
> > > > Does it make sense to add "clear_regs" and "clear_flags" actions in
> > > > order to address that concern?
> > >
> > > > I would also need to add in_port to symtab in
> ovn/lib/logical-fields.c so
> > > > that I can clear it.
> > >
> > > Can you explain why in_port needs to be cleared?
> > >
> >
> > My thought was that the packet should look like it arrived on the
> > distributed gateway port.
> > One question is whether there can be any bad implications if
> > in_port and logical inport do not match?
> > It is also possible that the packet will return back to the original
> > port after SNAT and DNAT on the distributed gateway port, so
> > if I do not clear in_port then I would have to set flags.loopback.
>
> Once a packet has been translated from physical to logical, the only
> real use of in_port is to discard packets that would loop back on the
> physical input port.  If we want to disable that, one way to do it is to
> set flags.loopback to 1, although that also disables discarding packets
> that would loop back to the logical input port.
>

I was thinking that egress loopback should be similar to traversing a
logical patch port. When traversing a logical patch port, in_port is
cleared.

If you have a problem with adding in_port to symtab, then I can just
set flags.loopback to 1. I would rather have the loopback check, but
at the moment add_route in ovn-northd.c sets flags.loopback to 1 in
all cases, so there is no difference on a logical router. Otherwise, I
will probably throw in a small patch to add in_port to symtab.

Mickey
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to