"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? Ryan Moats Ryan Moats _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
