On Wed, Nov 30, 2016 at 2:18 PM, Ben Pfaff <[email protected]> wrote:
> On Thu, Nov 03, 2016 at 12:09:21AM -0700, Mickey Spiegel wrote:
> > This patch set is being sent out early to solicit feedback on the
> > approach. North/south DNAT and SNAT are working, including some
> > automated tests. There is another patch required to get east/west NAT
> > working, but work has not yet commenced:
> >
> > 1. Add egress loopback capability, along with associated
> > flags.egress_loopback. When flags.egress_loopback is set, at the
> > end of the egress pipeline, instead of the packet being sent 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 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.
>
> Guru reminded me that we talked about this briefly at ovscon. I don't
> remember the conclusion or the suggestion. Is there anything I can do
> to help advance that discussion (or the patch series)?
>
Regarding egress loopback, you had suggested doing push and pop.
I am looking at such an approach now.
I seem to be missing something basic about multicast handling in OVS
and OVN. In Table 64, the "loopback" flag flow pushes MFF_IN_PORT,
clears MFF_IN_PORT, resubmits to table 65, then pops to restore
MFF_IN_PORT even though there is no further resubmit in this
particular flow.
Is the need for push and pop related to multicast?
Something to do with the handling of a packet that is resubmitted
multiple times at an earlier stage such as table 33?
I see comments suggesting a similar concern regarding pushing and
stripping VLAN tags in table 65:
/* Revert the tag added to the packets headed to containers
* in the previous step. If we don't do this, the packets
* that are to be broadcasted to a VM in the same logical
* switch will also contain the tag. */
Along the lines that you have suggested, I can start coding egress
loopback functionality. In table 65, I can add a priority 150 flow
matching EGRESS_LOOPBACK flag as well as dp_key and
outport. The actions will push various values, set or clear the
values, resubmit to the ingress pipeline, then pop to restore the
various values.
I am not sure whether to resubmit directly to
OFTABLE_LOGICAL_INGRESS_PIPELINE, or to
OFTABLE_PHY_TO_LOG?
Is it even possible to resubmit to OFTABLE_PHY_TO_LOG?
After overwriting MFF_IN_PORT?
The values to be set are:
MFF_IN_PORT (if resubmit to OFTABLE_PHY_TO_LOG)
MFF_LOG_INPORT (if resubmit to OFTABLE_LOGICAL_INGRESS_PIPELINE)
For egress loopback, there is no need to change
MFF_LOG_DATAPATH
MFF_LOG_CT_ZONE
MFF_LOG_DNAT_ZONE
MFF_LOG_SNAT_ZONE
The values to be cleared are:
MFF_LOG_OUTPORT
MFF_LOG_FLAGS
for (int i = 0; i < MFF_N_LOG_REGS; i++) {
MFF_REG0 + i
}
You also mentioned the thought of using this sort of approach
for patch ports in general. That requires more code to get the
peer mappings, either in terms of port_binding tunnel_key
(if resubmitting to OFTABLE_LOGICAL_INGRESS_PIPELINE)
or ofport (if resubmitting to OFTABLE_PHY_TO_LOG).
Mickey
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
