[ovs-discuss] OVN - VLAN packet duplicate processing on egress pipeline
Mark Michelson
mmichels at redhat.com
Mon Jul 23 13:00:10 UTC 2018
On 07/23/2018 08:03 AM, Anil Venkata wrote:
> Packets destined for VLAN remote logical ports are sent out through
> physical table 65 rather than physical table 32 (Geneve remote logical
> ports are sent through table 32). I found below description in ovn
> architecture documentation.
>
> http://www.openvswitch.org//support/dist-docs/ovn-architecture.7.html
>
> A special case is that when a localnet port exists on the
> datapath, remote port is connected by switching to the local‐
> net port. In this case, instead of adding a flow in table 32
> to reach the remote port, a flow is added in table 33 to
> switch the logical outport to the localnet port, and resubmit
> to table 33 as if it were unicasted to a logical port on the
> local hypervisor.
>
>
> Any reason for this decision. Because of this, packet is redundantly
> processed in logical switch's egress pipeline on both local and remote
> hypervisors.
Keep in mind that from OVN's perspective, a localnet port represents a
local exit from the logical switch. It doesn't know if the packet will
end up back in br-int again on another hypervisor. It would be equally
valid for the packet to be modified by a separate OVS switch and sent
out of the underlay network entirely once it has gone out the localnet
port. Thus if it does not go through the egress pipeline of the local
hypervisor, there is the chance that it will not go through the egress
pipeline of the logical switch at all.
There are potential ways that we could get around this redundant
processing. However, before suggesting anything concrete or actually
proposing that anything actually should be done, I'll echo Russell's
question about whether this is actually causing a noticeable problem.
>
> Thanks
> Anil
>
>
>
>
>
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
More information about the discuss
mailing list