On Tue, Jun 14, 2016 at 8:28 AM, Ryan Moats <rmo...@us.ibm.com> wrote:
> "dev" <dev-boun...@openvswitch.org> wrote on 06/08/2016 04:30:34 PM: > > > From: Darrell Ball <dlu...@gmail.com> > > To: dlu...@gmail.com, d...@openvswitch.com > > Date: 06/08/2016 04:31 PM > > Subject: [ovs-dev] [patch_v2] ovn: Fix receive from vxlan in > ovn-controller. > > Sent by: "dev" <dev-boun...@openvswitch.org> > > > > > 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. > > > > Some micro-details (e.g.) register assignments) that may change over time > > were moved from the ovn-architecture.7.xml document to the OVN-DESIGN.md > > document. The OVN-DESIGN.md file was tested using the following markdown > > parsers: > > > > https://jbt.github.io/markdown-editor/ > > http://dillinger.io/ > > > > 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> > > --- > > > > v1->v2: Rebased after recent conflicting commit. Converted some xml > > comments ported from the ovn-architecture document. Removed redundant > > register initialization and unnecessary bit declaration. > > > > ovn/OVN-DESIGN.md | 180 > +++++++++++++++++++++++++++++++++++++++++++ > > ovn/automake.mk | 1 + > > ovn/controller-vtep/vtep.c | 4 + > > ovn/controller/physical.c | 25 ++++-- > > ovn/lib/logical-fields.h | 13 +++- > > ovn/ovn-architecture.7.xml | 188 > > --------------------------------------------- > > tests/ovn.at | 3 + > > 7 files changed, 219 insertions(+), 195 deletions(-) > > create mode 100644 ovn/OVN-DESIGN.md > > > > diff --git a/ovn/OVN-DESIGN.md b/ovn/OVN-DESIGN.md > > new file mode 100644 > > index 0000000..6676de5 > > --- /dev/null > > +++ b/ovn/OVN-DESIGN.md > > @@ -0,0 +1,180 @@ > > +OVN register and metadata usage: > > +------------------------------- > > + > > +logical datapath field: > > + > > +A field that denotes the logical datapath through which a packet is > being > > +processed. > > +_Keep the following in sync with MFF_LOG_DATAPATH in_ > > +_ovn/lib/logical-fields.h._ > > +OVN uses the field that OpenFlow 1.1+ simply (and confusingly) calls > > +'metadata' to store the logical datapath. (This field is passed across > > +tunnels as part of the tunnel key.) > > + > > + > > +logical input port field: > > + > > +A field that denotes the logical port from which the packet entered the > > +logical datapath. > > +_Keep the following in sync with MFF_LOG_INPORT in_ > > +_ovn/lib/logical-fields.h._ > > +OVN stores this in Nicira extension register number 6. > > + > > +Geneve and STT tunnels pass this field as part of the tunnel key. > > +Although VXLAN tunnels do not explicitly carry a logical input port, > > +OVN only uses VXLAN to communicate with gateways that from OVN's > > +perspective consist of only a single logical port, so that OVN can set > > +the logical input port field to this one on ingress to the OVN logical > > +pipeline. > > + > > + > > +logical output port field: > > + > > +A field that denotes the logical port from which the packet will leave > > +the logical datapath. This is initialized to 0 at the beginning of the > > +logical ingress pipeline. > > +_Keep the following in sync with MFF_LOG_OUTPORT in_ > > +_ovn/lib/logical-fields.h._ > > +OVN stores this in Nicira extension register number 7. > > + > > +Geneve and STT tunnels pass this field as part of the tunnel key. VXLAN > > +tunnels do not transmit the logical output port field. > > + > > + > > +conntrack zone field for logical ports: > > + > > +A field that denotes the connection tracking zone for logical ports. > > +The value only has local significance and is not meaningful between > > +chassis. This is initialized to 0 at the beginning of the logical > > +ingress pipeline. OVN stores this in Nicira extension register number > 5. > > + > > + > > +conntrack zone fields for Gateway router: > > + > > +Fields that denote the connection tracking zones for Gateway routers. > > +These values only have local significance (only on chassis that have > > +Gateway routers instantiated) and is not meaningful between > > +chassis. OVN stores the zone information for DNATting in Nicira > > +extension register number 3 and zone information for SNATing in Nicira > > +extension register number 4. > > + > > + > > +flags field: > > + > > +Scratchpad flags that denote the pipeline state between tables. The > > +values only have local significance and are not meaningful between > > +chassis. This is initialized to 0 at the beginning of the logical > > +ingress pipeline. > > +_Keep the following in sync with MFF_LOG_FLAGS in_ > > +_ovn/lib/logical-fields.h._ > > +OVN stores this in Nicira extension register number 2. > > + > > + > > +VLAN ID: > > + > > +The VLAN ID is used as an interface between OVN and containers nested > > +inside a VM (see Life Cycle of a container interface inside a VM, in > > +ovn-architecture.7.xml, for more information). > > + > > + > > +The following table summarizes the register and metadata usage for OVN: > > + > > +``` > > + Register/Metadata Usage Bits (Used/Total) > > + ---------------- --------- -------------- > > + MFF_METADATA logical datapath 24/64 > > + MFF_REG0 ipv4 address 32/32 > > + MFF_REG1 ipv4 address 32/32 > > + MFF_REG2 flags 1/32 > > + MFF_REG3 conntrack dnat zone gateway 16/32 > > + MFF_REG4 conntrack snat zone gateway 16/32 > > + MFF_REG5 conntrack zone logical ports 16/32 > > + MFF_REG6 logical input port 15/32 > > + MFF_REG7 logical output port 16/32 > > +``` > > Yes, this is pedantic, but it's jarring to a reader to have REG0 and REG1 > introduced in the summary table and not discussed in previous paragraphs - > especially with the usage being just "ipv4 address" - do we mean to imply > that REG0 and REG1 carry the same data? > This document is intended for folks making changes to code. REG0 and REG1 are used are generic scratch registers; i.e. they don't have and are not intended to have designated usages at this time: I gave example usages of these scratch registers that use the full 32 bits to simply communicate that the full bit range is used in at least some cases. I will change the usage comment from "ipv4 address" to "generic scratch" and leave the bit usage at 32/32 to make this clear. > > > Ryan Moats > > Ryan Moats > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
