On Fri, Jan 06, 2017 at 04:28:00PM -0800, Mickey Spiegel wrote: > On Fri, Jan 6, 2017 at 3:57 PM, Ben Pfaff <[email protected]> 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 <[email protected]> > > > > 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.) _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
