struct ofputil_packet_in mixes data included in OpenFlow packet_in messages
with data that used internally by ofproto and connmgr to queue and route
packet_ins. This commit begins disentangling these purposes by adding a
new struct ofproto_packet_in that wraps struct ofputil_packet_in. Adding
this new level of indirection causes a lot of code churn, so this commit
mainly takes care of that to make the remaining changes easier to read.
This commit does move the list node used for queuing packet_ins into the
new wrapper structure.
Signed-off-by: Ben Pfaff <blp@nicira.com>
This makes 'ofproto_mutex' protect the flow table well enough that threads
other than the main one can realistically modify flows.
I need to look at the interface between ofproto and connmgr: I think that
there might need to be some locking there too.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
OpenFlow actions have always been somewhat awkward to handle.
Moreover, over time we've started creating actions that require more
complicated parsing. When we maintain those actions internally in
their wire format, we end up parsing them multiple times, whenever
we have to look at the set of actions.
When we add support for OpenFlow 1.1 or later protocols, the situation
will get worse, because these newer protocols support many of the same
actions but with different representations. It becomes unrealistic to
handle each protocol in its wire format.
This commit adopts a new strategy, by converting OpenFlow actions into
an internal form from the wire format when they are read, and converting
them back to the wire format when flows are dumped. I believe that this
will be more maintainable over time.
Thanks to Simon Horman and Pravin Shelar for reviews.
Signed-off-by: Ben Pfaff <blp@nicira.com>
The name compose_rarp() more clearly describes what it's doing now.
Requested-by: Justin Pettit <jpettit@nicira.com>
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Traditionally Open vSwitch had used 802.2 SNAP packets to update
upstream switch learning tables when necessary. This approach had
advantages in that debugging information could be embedded in the
packet helping hapless admins figure out what's going on. However,
since both qemu and VMware use RARP for this purpose, it seems
appropriate to fall in line with the defacto standard.
Requested-by: Ben Basler <bbasler@nicira.com>
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Otherwise even controllers that should not receive any packet-ins (via
enable-async-messages=false) still receive the packet-ins that probe for
a controller being up when we're in fail-open.
Bug #9964.
Reported-by: James Schmidt <jschmidt@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
An upcoming commit will start referring to OpenFlow 1.1 actions, which are
renumbered relative to OpenFlow 1.0 actions, so this commit prepares by
changing all the existing uses of OFPAT_* to instead use OFPAT10_*.
This commit also introduces the OFPAT11_* constants.
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Back in 2008 or so, I introduced this extension as a way to provide
information about switch status to the new "switch UI" program. Since
then, the switch UI program has been removed and the important information
that was provided by the switch status extension is now available in the
database, so we might as well get rid of this extension, and that is what
this commit does.
None of the existing callers of ofproto_add_flow() want an idle timeout,
but ofproto_add_flow() was giving them a 5-second timeout anyway. I don't
know how this worked properly--in-band will patiently add the flow back
every few seconds anyway, but the bridge doesn't do that.
Also add an explanatory comment to ofproto_add_flow().
When userspace and the kernel were using the same structure for flows,
flow_t was a useful way to indicate that a structure was really a userspace
flow instead of a kernel one, but now it's better to just write "struct
flow" for consistency, since OVS doesn't use typedefs for structs
elsewhere.
Acked-by: Jesse Gross <jesse@nicira.com>
Adding a macro to define the vlog module in use adds a level of
indirection, which makes it easier to change how the vlog module must be
defined. A followup commit needs to do that, so getting these widespread
changes out of the way first should make that commit easier to review.
The main purpose of the vconn code is to ship OpenFlow messages across
network connections. Over time a large number of utility functions related
to OpenFlow messages have also crept into vconn.c, but that's really
logically separate. This commit breaks those functions out into a new
file.
With this commit, Open vSwitch permits a bridge to have any number of
OpenFlow controllers. When multiple controllers are configured, Open
vSwitch connects to all of them simultaneously. Details of configuration
are in the vswitch schema documentation.
OpenFlow 1.0 does not specify how multiple controllers coordinate in
interacting with a single switch, so more than one controller should be
specified only if the controllers are themselves designed to coordinate
with each other.
An upcoming commit will provide a simple means for coordination between
multiple controllers.
Feature #2495.
Add a tun_id field which contains the ID of the encapsulating tunnel
on which a packet was received (0 if not received on a tunnel). Also
add an action which allows the tunnel ID to be set for outgoing
packets. At this point there aren't any tunnel implementations so
these fields don't have any effect.
The matching is exposed to OpenFlow by overloading the high 32 bits
of the cookie as the tunnel ID. ovs-ofctl is capable of turning
on this special behavior using a new "tun-cookie" command but this
command is intentially undocumented to avoid it being used without
a full understanding of the consequences.
fail_open_destroy() was not deleting the fail-open flow, so turning off
fail-open mode did not work if fail-open had already been triggered.
This commit fixes the problem.
Reported by Paul Ingram <paul@nicira.com>.
In places where a random Ethernet address needs to be generated we
are inconsistent about setting an OUI. This sets an OUI everywhere
to allow the source of packets to be easily identified.
This was a somewhat difficult merge since there was a fair amount of
superficially divergent development on the two branches, especially in the
datapath.
This has been build-tested against XenServer 5.5.0 and XenServer 5.7.0
build 15122. It has been booted and connected to XenCenter on 5.5.0.
The merge revealed a couple of outstanding bugs, which will be fixed on
citrix and then merged back into master.
