On Wed, Jun 01, 2016 at 10:34:24AM -0700, Darrell Ball wrote: > OVN only supports source_node replication and previously vtep interaction, > which used service node replication by default for multicast/broadcast/unknown > unicast traffic worked by happenstance. Because of limited vxlan > encapsulation metadata, received packets were resubmitted to find the egress > port(s). This is not correct for multicast, broadcast and unknown unicast > traffic > as traffic will get resent on the tunnel mesh. ovn-controller is changed not > to > send traffic received from vxlan tunnels out the tunnel mesh again. Traffic > received from vxlan tunnels is now only sent locally as intended. > > To support keeping state for receipt from a vxlan tunnel a MFF logical > register is allocated for general scratchpad purposes and one bit is used for > receipt from vxlan. The new register usage is documented in a new > OVN-DESIGN.md document and a table is added to track MFF logical metadata > and register usage. > > As part of this change ovn-controller-vtep is hard-coded to set the > replication > mode of each logical switch to source node as OVN will only support source > node replication. > > Signed-off-by: Darrell Ball <dlu...@gmail.com>
This failed to apply due to patch rejects so I'm reviewing on the basis of just reading the patch. We already have a nicely formatted manpage in ovn-architecture(7). Please don't delete text from it and put it into a more poorly formatted .md file that tries to use XML comments (!). I don't see how it's any kind of improvement. It shouldn't be necessary to initialize the flags register to 0 in table 0, because all registers are initially 0 at the beginning of the OpenFlow pipeline. We don't usually bother having separate declarations for the bit offset of a flag within a register, because it is rarely useful. Thanks, Ben. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
