On Tue, Jun 7, 2016 at 8:50 AM, Ben Pfaff <b...@ovn.org> wrote: > 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. >
Yes, recent conflicting commits will require a rebase here. > > 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. > Thanks; there are 5 comment usages that need to be converted; I missed those while focusing on the other content and formatting. Just to avoid some back and forth: 1) Are you ok with the general idea of moving some OVN design details into a separate file ? 2) If the answer to "1" is "yes", is it ok for the separate file to be a .md file, assuming all formatting is correct or a .xml file is preferred. > > 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. > I will double check and remove the redundant initialization. > > We don't usually bother having separate declarations for the bit offset > of a flag within a register, because it is rarely useful. > > I'll remove the unnecessary bit offset declaration. > Thanks, > > Ben. > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
