[ovs-git] [openvswitch/ovs] cb0503: actions: Make "free" functions per-struct, not per...

GitHub noreply at github.com
Tue Jan 31 22:29:41 UTC 2017


  Branch: refs/heads/branch-2.7
  Home:   https://github.com/openvswitch/ovs
  Commit: cb0503a74fa4116f73c695bb5b0ce36580ce079e
      https://github.com/openvswitch/ovs/commit/cb0503a74fa4116f73c695bb5b0ce36580ce079e
  Author: Ben Pfaff <blp at ovn.org>
  Date:   2017-01-31 (Tue, 31 Jan 2017)

  Changed paths:
    M ovn/lib/actions.c

  Log Message:
  -----------
  actions: Make "free" functions per-struct, not per-action.

In some cases multiple kinds of OVN action share the same structure.  In
all of these cases, a given kind of structure is freed one particular way
(it would be confusing if this were not the case), so there's no benefit
in having per-action free functions.  Therefore, this commit switches to
a free function per structure type.

Signed-off-by: Ben Pfaff <blp at ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev at gmail.com>


  Commit: 9eceae9917656d512371b7d50c8f816f7fb30e46
      https://github.com/openvswitch/ovs/commit/9eceae9917656d512371b7d50c8f816f7fb30e46
  Author: Ben Pfaff <blp at ovn.org>
  Date:   2017-01-31 (Tue, 31 Jan 2017)

  Changed paths:
    M include/ovn/actions.h
    M ovn/lib/actions.c
    M ovn/ovn-sb.xml
    M ovn/utilities/ovn-trace.c
    M tests/ovn.at

  Log Message:
  -----------
  actions: Add new OVN action "clone".

Signed-off-by: Ben Pfaff <blp at ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev at gmail.com>


  Commit: e1e563a90475701262748eba9f54a7fc13a1fe2e
      https://github.com/openvswitch/ovs/commit/e1e563a90475701262748eba9f54a7fc13a1fe2e
  Author: Ben Pfaff <blp at ovn.org>
  Date:   2017-01-31 (Tue, 31 Jan 2017)

  Changed paths:
    M include/ovn/actions.h
    M ovn/lib/actions.c

  Log Message:
  -----------
  actions: Separate action structures for "next" and "ct_next".

These actions aren't very similar but until now they both had the same
action structure.  These structures are going to diverge in an upcoming
commit, so separate them now.

Signed-off-by: Ben Pfaff <blp at ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev at gmail.com>


  Commit: 6403ecbbc129f2e7197a011c220b12563d2dc183
      https://github.com/openvswitch/ovs/commit/6403ecbbc129f2e7197a011c220b12563d2dc183
  Author: Ben Pfaff <blp at ovn.org>
  Date:   2017-01-31 (Tue, 31 Jan 2017)

  Changed paths:
    M include/ovn/actions.h
    M ovn/lib/actions.c
    M tests/ovn.at

  Log Message:
  -----------
  actions: Omit table number when possible for formatting "next" action.

Until now, formatting the "next" action has always required including
the table number, because the action struct didn't include enough context
so that the formatter could decide whether the table number was the next
table or some other table.  This is more or less OK, but an upcoming commit
will add a "pipeline" field to the "next" action, which means that the same
policy there would require that the pipeline always be printed.  That's a
little obnoxious because 99+% of the time, the pipeline to be printed is
the same pipeline that the flow is in and printing it would be distracting.
So it's better to store some context to help with formatting.  This commit
begins adopting that policy for the existing table number field.

Signed-off-by: Ben Pfaff <blp at ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev at gmail.com>


  Commit: 5f89aa2bd666abba017735b2d73b306696ce41d3
      https://github.com/openvswitch/ovs/commit/5f89aa2bd666abba017735b2d73b306696ce41d3
  Author: Ben Pfaff <blp at ovn.org>
  Date:   2017-01-31 (Tue, 31 Jan 2017)

  Changed paths:
    M include/ovn/actions.h
    M ovn/utilities/ovn-trace.c

  Log Message:
  -----------
  actions: Introduce enum ovnact_pipeline.

This isn't used yet by the actions code, but an upcoming commit will
introduce a user.  This commit just adjusts ovn-trace to use this common
type instead of its own local type.

Signed-off-by: Ben Pfaff <blp at ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev at gmail.com>


  Commit: b5c0298a25790791be91a96706a171d649f15c96
      https://github.com/openvswitch/ovs/commit/b5c0298a25790791be91a96706a171d649f15c96
  Author: Ben Pfaff <blp at ovn.org>
  Date:   2017-01-31 (Tue, 31 Jan 2017)

  Changed paths:
    M include/ovn/actions.h
    M ovn/controller/lflow.c
    M ovn/lib/actions.c
    M ovn/ovn-sb.xml
    M ovn/utilities/ovn-trace.c
    M tests/ovn.at
    M tests/test-ovn.c

  Log Message:
  -----------
  actions: Make "next" action able to jump from egress to ingress pipeline.

This feature is useful for centralized gateways.

Signed-off-by: Ben Pfaff <blp at ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev at gmail.com>


  Commit: e65561b066afd71be5420891d9efd76b0075e6b5
      https://github.com/openvswitch/ovs/commit/e65561b066afd71be5420891d9efd76b0075e6b5
  Author: Ben Pfaff <blp at ovn.org>
  Date:   2017-01-31 (Tue, 31 Jan 2017)

  Changed paths:
    M include/ovn/actions.h
    M ovn/lib/actions.c
    M ovn/ovn-sb.xml
    M ovn/utilities/ovn-trace.c
    M tests/ovn.at

  Log Message:
  -----------
  actions: Add new "ct_clear" action.

Signed-off-by: Ben Pfaff <blp at ovn.org>
Acked-by: Mickey Spiegel <mickeys.dev at gmail.com>


  Commit: f9bac4fb9123eb108e611c7e40b10d4021840a3b
      https://github.com/openvswitch/ovs/commit/f9bac4fb9123eb108e611c7e40b10d4021840a3b
  Author: Mickey Spiegel <mickeys.dev at gmail.com>
  Date:   2017-01-31 (Tue, 31 Jan 2017)

  Changed paths:
    M include/ovn/expr.h
    M ovn/controller/lflow.c
    M ovn/controller/lflow.h
    M ovn/controller/ovn-controller.c
    M ovn/lib/expr.c
    M ovn/ovn-sb.xml
    M ovn/utilities/ovn-trace.c
    M tests/ovn.at
    M tests/test-ovn.c

  Log Message:
  -----------
  ovn: add is_chassis_resident match expression component

This patch introduces a new match expression component
is_chassis_resident().  Unlike match expression comparisons,
is_chassis_resident is not pushed down to OpenFlow.  It is a
conditional that is evaluated in the controller during expr_simplify(),
when it is replaced by a boolean expression.  The is_chassis_resident
conditional evaluates to "true" when the specified string identifies a
port name that is resident on this controller chassis, i.e., the
corresponding southbound database Port_Binding has a chassis column
that matches this chassis.  Otherwise it evaluates to "false".

This allows higher level features to specify flows that are only
installed on some chassis rather than on all chassis with the
corresponding datapath.

Suggested-by: Ben Pfaff <blp at ovn.org>
Signed-off-by: Mickey Spiegel <mickeys.dev at gmail.com>
Acked-by: Ben Pfaff <blp at ovn.org>
Signed-off-by: Ben Pfaff <blp at ovn.org>


  Commit: 4bfb0b5dca36a0ef19d58a735aed8ad4d39b468a
      https://github.com/openvswitch/ovs/commit/4bfb0b5dca36a0ef19d58a735aed8ad4d39b468a
  Author: Mickey Spiegel <mickeys.dev at gmail.com>
  Date:   2017-01-31 (Tue, 31 Jan 2017)

  Changed paths:
    M ovn/controller/binding.c
    M ovn/controller/ovn-controller.c
    M ovn/controller/physical.c
    M ovn/northd/ovn-northd.8.xml
    M ovn/northd/ovn-northd.c
    M ovn/ovn-architecture.7.xml
    M ovn/ovn-nb.ovsschema
    M ovn/ovn-nb.xml
    M ovn/ovn-sb.xml
    M ovn/utilities/ovn-trace.c
    M tests/ovn.at

  Log Message:
  -----------
  ovn: Introduce distributed gateway port and "chassisredirect" port binding

Currently OVN distributed logical routers achieve reachability to
physical networks by passing through a "join" logical switch to a
centralized gateway router, which then connects to another logical
switch that has a localnet port connecting to the physical network.

This patch adds logical port and port binding abstractions that allow
an OVN distributed logical router to connect directly to a logical
switch that has a localnet port connecting to the physical network.
In this patch, this logical router port is called a "distributed
gateway port".

The primary design goal of distributed gateway ports is to allow as
much traffic as possible to be handled locally on the hypervisor
where a VM or container resides.  Whenever possible, packets from
the VM or container to the outside world should be processed
completely on that VM's or container's hypervisor, eventually
traversing a localnet port instance on that hypervisor to the
physical network.  Whenever possible, packets from the outside
world to a VM or container should be directed through the physical
network directly to the VM's or container's hypervisor, where the
packet will enter the integration bridge through a localnet port.

However, due to the implications of the use of L2 learning in the
physical network, as well as the need to support advanced features
such as one-to-many NAT (aka IP masquerading), where multiple
logical IP addresses spread across multiple chassis are mapped to
one external IP address, it will be necessary to handle some of the
logical router processing on a specific chassis in a centralized
manner.  For this reason, the user must associate a chassis with
each distributed gateway port.

In order to allow for the distributed processing of some packets,
distributed gateway ports need to be logical patch ports that
effectively reside on every hypervisor, rather than "l3gateway"
ports that are bound to a particular chassis.  However, the flows
associated with distributed gateway ports often need to be
associated with physical locations.  This is implemented in this
patch (and subsequent patches) by adding "is_chassis_resident()"
match conditions to several logical router flows.

While most of the physical location dependent aspects of distributed
gateway ports can be handled by restricting some flows to specific
chassis, one additional mechanism is required.  When a packet
leaves the ingress pipeline and the logical egress port is the
distributed gateway port, one of two different sets of actions is
required at table 32:
- If the packet can be handled locally on the sender's hypervisor
  (e.g. one-to-one NAT traffic), then the packet should just be
  resubmitted locally to table 33, in the normal manner for
  distributed logical patch ports.
- However, if the packet needs to be handled on the chassis
  associated with the distributed gateway port (e.g. one-to-many
  SNAT traffic or non-NAT traffic), then table 32 must send the
  packet on a tunnel port to that chassis.
In order to trigger the second set of actions, the
"chassisredirect" type of southbound port_binding is introduced.
Setting the logical egress port to the type "chassisredirect"
logical port is simply a way to indicate that although the packet
is destined for the distributed gateway port, it needs to be
redirected to a different chassis.  At table 32, packets with this
logical egress port are sent to a specific chassis, in the same
way that table 32 directs packets whose logical egress port is a
VIF or a type "l3gateway" port to different chassis.  Once the
packet arrives at that chassis, table 33 resets the logical egress
port to the value representing the distributed gateway port.  For
each distributed gateway port, there is one type "chassisredirect"
port, in addition to the distributed logical patch port
representing the distributed gateway port.

A "chassisredirect" port represents a particular instance, bound
to a specific chassis, of an otherwise distributed port.  A
"chassisredirect" port is associated with a chassis in the same
manner as a "l3gateway" port.  However, unlike "l3gateway" ports,
"chassisredirect" ports have no associated IP or MAC addresses,
and "chassisredirect" ports should never be used as the "inport".
Any pipeline stages that depend on port specific IP or MAC addresses
should be carried out in the context of the distributed gateway
port's logical patch port.

Although the abstraction represented by the "chassisredirect" port
binding is generalized, in this patch the "chassisredirect" port binding
is only created for NB logical router ports that specify the new
"redirect-chassis" option.  There is no explicit notion of a
"chassisredirect" port in the NB database.  The expectation is when
capabilities are implemented that take advantage of "chassisredirect"
ports (e.g. distributed gateway ports), flows specifying a
"chassisredirect" port as the outport will be added as part of that
capability.

Signed-off-by: Mickey Spiegel <mickeys.dev at gmail.com>
Signed-off-by: Ben Pfaff <blp at ovn.org>


Compare: https://github.com/openvswitch/ovs/compare/c3bfa9972f22...4bfb0b5dca36


More information about the git mailing list