hmm, it looks like a logical flags register was added by Justin recently hence there is no need for me to add that.
Since this patch or patch series has been out for about 2 months and there has been some disagreement regarding documentation refactoring, it might be best to coordinate this closely with some folks. On Mon, Aug 8, 2016 at 12:57 PM, Darrell Ball <dlu...@gmail.com> wrote: > > > On Sat, Aug 6, 2016 at 12:38 PM, Ryan Moats <rmo...@us.ibm.com> wrote: > >> "dev" <dev-boun...@openvswitch.org> wrote on 07/29/2016 06:08:38 PM: >> >> > From: Darrell Ball <dlu...@gmail.com> >> > To: dlu...@gmail.com, d...@openvswitch.com, b...@ovn.org >> > Date: 07/29/2016 06:09 PM >> > Subject: [ovs-dev] [patch_v7] ovn: Fix receive from vxlan in >> ovn-controller. >> > Sent by: "dev" <dev-boun...@openvswitch.org> >> > >> > The changes enable source node replication in OVN for receive from Vxlan >> > tunnels. OVN only supports source node replication mode. This is >> needed >> > for OVN to interoperate with hardware switches. >> > >> > 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 with obvious benefits. This behavior >> is >> > newly documented in ovn-architecture.7.xml. >> > >> > 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 >> > ovn-architecture.7.xml. >> > >> > 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> >> > --- >> >> I was going to try this out, but the patches to ovn/lib/logical-fields.h >> didn't apply cleanly and it looks like some of the changes are already >> there, so rather than guess what goes in and doesn't, can we get a rebase? >> >> >> > hmm, it looks like a logical flags register was added by Justin recently > hence > there is no need for me to add that. > > Since this patch or patch series has been out for a about 2 months and > there > has been some disagreement regarding document > > > > On Mon, Aug 8, 2016 at 12:57 PM, Darrell Ball <dlu...@gmail.com> wrote: > > > On Sat, Aug 6, 2016 at 12:38 PM, Ryan Moats <rmo...@us.ibm.com> wrote: > >> "dev" <dev-boun...@openvswitch.org> wrote on 07/29/2016 06:08:38 PM: >> >> > From: Darrell Ball <dlu...@gmail.com> >> > To: dlu...@gmail.com, d...@openvswitch.com, b...@ovn.org >> > Date: 07/29/2016 06:09 PM >> > Subject: [ovs-dev] [patch_v7] ovn: Fix receive from vxlan in >> ovn-controller. >> > Sent by: "dev" <dev-boun...@openvswitch.org> >> > >> > The changes enable source node replication in OVN for receive from Vxlan >> > tunnels. OVN only supports source node replication mode. This is >> needed >> > for OVN to interoperate with hardware switches. >> > >> > 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 with obvious benefits. This behavior >> is >> > newly documented in ovn-architecture.7.xml. >> > >> > 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 >> > ovn-architecture.7.xml. >> > >> > 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> >> > --- >> >> I was going to try this out, but the patches to ovn/lib/logical-fields.h >> didn't apply cleanly and it looks like some of the changes are already >> there, so rather than guess what goes in and doesn't, can we get a rebase? >> >> >> > hmm, it looks like a logical flags register was added by Justin recently > hence > there is no need for me to add that. > > Since this patch or patch series has been out for a about 2 months and > there > has been some disagreement regarding document > > > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
