On Mon, Jan 9, 2017 at 2:22 PM, Ben Pfaff <[email protected]> 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 <[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.) >
Probably the register bit setting should be within the clone. Are you OK with setting a specific register bit in an OVN action definition? Mickey _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
