[ovs-dev] [PATCH v7 4/7] ovn: add egress loopback capability

Ben Pfaff blp at ovn.org
Mon Jan 9 22:44:40 UTC 2017


On Mon, Jan 09, 2017 at 02:30:54PM -0800, Mickey Spiegel wrote:
> On Mon, Jan 9, 2017 at 2:22 PM, Ben Pfaff <blp at ovn.org> wrote:
> 
> > On Fri, Jan 06, 2017 at 04:28:00PM -0800, Mickey Spiegel wrote:
> > > On Fri, Jan 6, 2017 at 3:57 PM, Ben Pfaff <blp at ovn.org> wrote:
> > >
> > > > On Fri, Jan 06, 2017 at 12:00:31PM -0800, Mickey Spiegel wrote:
> > > > > This patch adds the capability to force loopback at the end of the
> > > > > egress pipeline.  A new flags.force_egress_loopback symbol is
> > defined,
> > > > > along with corresponding flags bits.  When
> > flags.force_egress_loopback
> > > > > is set, at OFTABLE_LOG_TO_PHY, instead of the packet being sent out
> > to
> > > > > the peer patch port or out the outport, the packet is forced back to
> > > > > the beginning of the ingress pipeline with inport = outport.  All
> > > > > other registers are cleared, as if the packet just arrived on that
> > > > > inport.
> > > > >
> > > > > This capability is needed in order to implement some of the east/west
> > > > > distributed NAT flows.
> > > > >
> > > > > Note: The existing flags.loopback allows a packet to go from the end
> > > > > of the ingress pipeline to the beginning of the egress pipeline with
> > > > > outport = inport, which is different.
> > > > >
> > > > > Initially, there are no tests incorporated in this patch.  This
> > > > > functionality is tested in a subsequent distributed NAT flows patch.
> > > > > Tests specific to egress loopback may be added once the capability
> > > > > to inject a packet with one of the flags bits set is added.
> > > > >
> > > > > Signed-off-by: Mickey Spiegel <mickeys.dev at gmail.com>
> > > >
> > > > I don't really understand this yet.
> > > >
> > > > Does this need to be a flag or can it be an action, i.e. one that
> > > > immediately jumps back to the beginning of the ingress pipeline.  Then
> > > > we don't need hard-coded flags, we can just have used-defined register
> > > > bits, etc.
> > > >
> > >
> > > Since I am figuring out whether to do egress loopback at the end of
> > > the egress pipeline, I could get rid of the FORCE_EGRESS_LOOPBACK
> > > flag and use an action instead.
> >
> > OK.
> >
> > > I think I still need the EGRESS_LOOPBACK_OCCURRED bit to avoid
> > > the packet getting dropped in table 1 because the logical router receives
> > > a packet with its own IP address as source.
> >
> > I think that could be avoided, too, with a little more adjustment.
> > First, instead of zeroing all the registers, maintain them (and then
> > zero registers that should be zeroed using OVN logical actions).
> > Second, use some designated bit in a register for this particular
> > purpose.
> >
> > (In case it is not clear, my preference, overall, is to put policy, as
> > much as possible, into the logical flow table instead of into the
> > mechanism that surrounds it.)
> >
> 
> Probably the register bit setting should be within the clone.
> Are you OK with setting a specific register bit in an OVN action definition?

What do you mean by "within the clone"?

To clarify what I'm talking about, I was expecting something like this
to appear in the OVN logical actions:
    reg0=0; reg1=0; reg2=0; ...; regX[Y] = 1; recirculate;
Maybe we need to save and restore the registers around the
recirculation, in which case we can define a new OVN logical action that
does that, e.g. maybe an OVN clone action:
    clone { reg0=0; reg1=0; reg2=0; ...; regX[Y] = 1; recirculate; }


More information about the dev mailing list