| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
Until now, ovs-vsctl has kept trying to the database server until it
succeeded or the timeout expired (if one was specified with --timeout).
This meant that if ovsdb-server wasn't running, then ovs-vsctl would hang.
The result was that almost every ovs-vsctl invocation in scripts specified
a timeout on the off-chance that the database server might not be running.
But it's difficult to choose a good timeout. A timeout that is too short
can cause spurious failures. A timeout that is too long causes long delays
if the server really isn't running.
This commit should alleviate this problem. It changes ovs-vsctl's behavior
so that, if it fails to connect to the server, it exits unsuccessfully.
This makes --timeout obsolete for the purpose of avoiding a hang if the
database server isn't running. (--timeout is still useful to avoid a hang
if ovsdb-server is running but ovs-vswitchd is not, for ovs-vsctl commands
that modify the database. --no-wait also avoids that issue.)
Bug #2393.
Bug #15594.
Reported-by: Jeff Merrick <jmerrick@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
This also sets the dates for 1.8.0, even though it was an internal-only
release.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
Signed-off-by: Jesse Gross <jesse@nicira.com>
Conflicts:
NEWS
|
|
Feature #15466.
Requested-by: Ronghua Zhang <rzhang@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
The CAPWAP implementation is just the encapsulation format and
therefore really not the full protocol. While there were some
uses of it (primarily hardware support and UDP transport). But
these are most likely better provided by VXLAN.
Following patch removes CAPWAP tunneling support.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
|
|
The VXLAN draft just got updated from -02 to -03, with no major changes.
Update documentation to reflect the change.
Signed-off-by: Lorand Jakab <lojakab@cisco.com>
Acked-by: Kyle Mestery <kmestery@cisco.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
|
|
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
Suggested-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
A few items were listed as arriving in 1.9.0, but they actually were new
to 1.10.0.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
With this patch, ovs-vswitchd uses flow based tunneling
exclusively. I.E. each kind of tunnel shares a single tunnel
backer in the datapath. Tunnel headers are set by userspace using
the ipv4_tunnel datapath action. And, the configuration of
individual tunnels is now a userspace responsibility, so
netdev-vport no longer marshals and unmarshals Netlink attributes
for tunnel configuration, instead only storing the configuration
internally. There are still some significant pieces of work to do,
but the basic building blocks are there to begin testing.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Co-authored-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
|
|
This commit moves responsibility for implementing patch ports from
the datapath to ofproto-dpif. There are two main reasons to do
this.
The first is a matter of design: ofproto-dpif both has more
information than the datapath, and is better suited to handle the
complexity required to implement patch ports.
The second is performance. My setup is a virtual machine with two
basic learning bridges connected by patch ports. I used
ovs-benchmark to ping the virtual router IP residing outside the
VM. Over a 60 second run, "ovs-benchmark rate" improves from
14618.1 to 19311.9 transactions per second, or a 32% improvement.
Similarly, "ovs-benchmark latency" improves from 6ms to 4ms.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
|
|
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
A few ovs-vsctl commands have accepted --if-exists options for some time,
to make it possible to execute them in cases where it doesn't really
matter if the records they touch exist. This commit adds this option to
other commands.
This is intended for initial use with "ovs-vsctl set interface <iface>
ofport_request=<number>" commands in ovs-ctl for upgrades from OVS 1.9
to later versions.
This makes a very small incompatible change to the ovs-vsctl "get"
command: previously with --if-exists, only keys in map columns were
allowed to be missing; now with --if-eixsts, also records are allowed
to be missing.
CC: Gurucharan Shetty <gshetty@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Add Linux 3.8 kernel to the range of supported kernel versions.
Signed-off-by: James Page <james.page@ubuntu.com>
[jesse: Update NEWS and FAQ]
Signed-off-by: Jesse Gross <jesse@nicira.com>
|
|
This will be required to support flow based tunneling.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
|
|
Userspace-kernel communication is a possible bottleneck when OVS is
receiving a large number of flow set up requests. To help prevent a bad
actor from consuming too much of this resource, we introduced channels
to segegrate traffic. Previously, we created 17 channels and
round-robin assigned ports to one of 16 channels (the 17th was reserved
for use by the system). This meant if there were more than 16 ports,
sharing of channels would occur.
This commit creates a new channel for each port, so that there is no
more sharing and better isolation. The special system port uses the
"ovs-system"'s channel (port 0), since it is not heavily loaded.
This also fixes an issue introduced in commit acf60855 (ofproto-dpif:
Use a single underlying datapath across multiple bridges.) where ports
that were added at run-time were given the special system channel.
Issue #12073
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
Currently we use "*" or ANY to mark a field in flow syntax
as a wildcard. With ANY being a valid openflow port now,
there is a conflict for in_port field. So at the least, we
need to remove ANY from being considered as a wildcard for
in_port. But this may cause general confusion and it may be
a better idea to remove 'ANY' as a wildcard for all fields.
Signed-off-by: Gurucharan Shetty <gshetty@nicira.com>
|
|
This patch removes path MTU discovery from userspace. The feature
still exists in the kernel where it will need to be removed in the
future.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
|
|
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
bug #14341
|
|
Signed-off-by: Felician Nemeth <nemethf@tmit.bme.hu>
[blp@nicira.com refactored the code that this was based on and revised the
patch accordingly]
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
datapath: backport 15e473046cb6e5d18a4d0057e61d76315230382b
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
[jesse: fix kernel version in error message]
Signed-off-by: Jesse Gross <jesse@nicira.com>
|
|
We've had a couple of requests for this over the years. It's easy to do,
so let's implement it.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Kyle Mestery <kmestery@cisco.com>
|
|
A few times while troubleshooting it would have been useful to get
complete logs, rather than post-rate-limiting snapshots of them. These
ovs-appctl commands make that possible.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Add support for VXLAN tunnels to Open vSwitch. Add support
for setting the destination UDP port on a per-port basis.
This is done by adding a "dst_port" parameter to the port
configuration. This is only applicable currently to VXLAN
tunnels.
Please note this currently does not implement any sort of multicast
learning. With this patch, VXLAN tunnels must be configured similar
to GRE tunnels (e.g. point to point). A subsequent patch will implement
a VXLAN control plane in userspace to handle multicast learning.
This patch set is based on one posted by Ben Pfaff on Oct. 12, 2011
to the ovs-dev mailing list:
http://openvswitch.org/pipermail/dev/2011-October/012051.html
The patch has been maintained, updated, and freshened by me and a
version of it is available at the following github repository:
https://github.com/mestery/ovs-vxlan/tree/vxlan
I've tested this patch with multiple VXLAN tunnels between hosts
using different UDP port numbers. Performance is on par (though
slightly faster) than comparable GRE tunnels.
See the following IETF draft for additional information about VXLAN:
http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-02
Signed-off-by: Kyle Mestery <kmestery@cisco.com>
[jesse: simplify error path in vxlan_tunnel_setup, don't print default VXLAN port,
and remove dead code]
Signed-off-by: Jesse Gross <jesse@nicira.com>
|
|
This patch adds support for skb mark matching and set action.
Acked-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
|
|
This patch adds ipv6 set action functionality. It allows to change
traffic class, flow label, hop-limit, ipv6 source and destination
address fields.
Acked-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
|
|
Tunnel caching was added to reduce CPU utilization on TX path
by caching packet header, So performance gain is directly proportional
to number of skbs transferred. But with help of offloads skb are getting
larger. So there are less number of skbs. Therefore header caching does
not shows similar gains we seen in past. And now kernel 3.6 has removed
dst caching from networking which makes header caching even more tricky.
So this commit removes header caching from OVS tunnelling.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
|
|
The CAPWAP implementation is just the encapsulation format and
therefore really not the full protocol. While there were some
uses of it (primarily hardware support and UDP transport). But
these are most likely better provided by VXLAN. As a result,
CAPWAP will be removed no earlier than February 2013.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
|
|
This commit updates NEWS and debian/changelog to reflect that
commit 8087f5ff (Process RARP packets with ethertype 0x8035
similar to ARP packets.) is going to be backported intto 1.9.0, so
that they should no longer be listed as post-1.9 features.
Signed-off-by: Mehak Mahajan <mmahajan@nicira.com>
|
|
With this commit, OVS will match the data in the RARP packets having
ethertype 0x8035, in the same way as the data in the ARP packets.
Signed-off-by: Mehak Mahajan <mmahajan@nicira.com>
|
|
This commit switches to using a single backing datapath (called
"ovs-datapath") for all bridges of that datapath's type. Previously,
resources couldn't be shared across bridges, since each was in its own
datapath. This change will allow sharing of tunnels and cheaper patch
ports to be added in the future.
Since bridges share a common datapath, the ovs-dpctl commands won't
provide bridge-specific information. Users wishing to have that
information should use the new "ovs-appctl dpif/*" commands as
documented in ovs-vswitchd(8).
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
A future commit will make all bridges use a single backing datapath.
This commit makes the "dp" argument for "dump-flows" and "del-flows"
optional, since there will typically only be one actual datapath.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
These commands will be useful in a future commit that makes multiple
bridges share a single backing datapath. The ovs-dpctl commands will
show information about the backing datapath, so it will be difficult to
determine which information belongs to which bridge. The new "dpif/*"
ovs-appctl commands return information about the bridge--regardless of
how the backing datapath is configured.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
In a future commit, we will make multiple bridges share a single backing
datapath. Our simple mapping from datapath to OpenFlow port numbers
won't work, since we'll want the same OpenFlow port numbers on different
bridges. For example, the OFPP_LOCAL port must be the same on all
bridges, but will have to be a different datapath port on the converged
datapath.
This commit makes it the responsibility of ofproto to assign the
OpenFlow port numbers instead of doing a simple translation from the
datapath ones.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
A new "ofport_request" column makes it possible to request the OpenFlow
port number when adding a port.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
|
|
This is a complementary patch to the other one I sent out previously.
The purpose of it is to make it more obvious that tunnel pmtud is
deprecated and will be removed soon.
Requested-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
|
|
In near future we will switch to the flow-based tunneling and drop path
MTU discovery support. This patch prepares for that by changing the default
PMTUD value from 'enabled' to 'disabled'.
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
|
|
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
This is a first pass at providing a tun_key which can be
used as the basis for flow-based tunnelling. The
tun_key includes and replaces the tun_id in both struct
ovs_skb_cb and struct sw_tun_key.
This patch allows all existing tun_id behaviour to still work. Existing
users of tun_id are redirected to tun_key->tun_id to retain compatibility.
However, when the userspace code is updated to make use of the new
tun_key, the old behaviour will be deprecated and removed.
NOTE: With these changes, the tunneling code no longer assumes input and
output keys are symmetric. If they are not, PMTUD needs to be disabled
for tunneling to work.
Signed-off-by: Kyle Mestery <kmestery@cisco.com>
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Reviewed-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
|
In OpenFlow 1.1, we add support for OFPIT_WRITE_METADATA. This allows us to
write to the metadata field. Internally it is represented using ofpact_metadata.
We introduce NXAST_WRITE_METADATA to handle writing to the metadata field in
OpenFlow 1.0+. This structure reflects OFPIT_WRITE_METADATA.
When writing out the structure to OpenFlow 1.1, it uses the OFPIT_WRITE_METADATA
instruction only, and not the new NXAST action (which would be redundant).
Signed-off-by: Joe Stringer <joe@wand.net.nz>
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Commit c6100d92142b (ovs-ofctl: Accept port keywords, OF1.1 port numbers,
reject port number 0.) intentionally prohibited using port 0, which is not
a valid OpenFlow port number, in OpenFlow commands and actions. However,
since then we have discovered that the NVP controller uses port 0 in
"resubmit" actions and hence in flow matches as well. This seems like a
valid enough use case; after all, the port number in a resubmit action is
really just an arbitrary number that need not (and preferably does not)
refer to an actual OpenFlow port. Therefore, this commit restores the
ability to use port 0.
(Only functions that parse OpenFlow commands and actions from strings, not
those that interpret binary OpenFlow coming in on OpenFlow connections,
were affected by this prohibition, so this only comes up in corner cases
anyhow.)
Reported-by: Gurucharan Shetty <gshetty@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Extend GRE to have a 64-bit key. Use GRE sequence number to
store upper 32-bits of the key, but this is not standard way of
using GRE sequence number.
Bug #13186
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
|
|
This is a necessary step toward supporting full 32-bit OF1.1+ port numbers
in a later version of OVS.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
|
|
OpenFlow 1.0 has special reserved ports in the range 0xfff8 to 0xffff.
OpenFlow 1.1 and later has the same ports in the range 0xfffffff8 to
0xffffffff and allows the OF1.0 range to be used for ordinary ("physical")
switch ports. This means that, naively, the meaning of a port number in
the range 0xfff8 to 0xffff given on the ovs-ofctl command line depends on
the protocol in use. This commit implements something a little smarter:
- Accept keyword names (e.g. LOCAL) for special reserved ports
everywhere that such a port can plausibly be used (previously they
were only accepted in some places).
- Translate 0xfff8...0xffff to 0xfffffff8...0xffffffff for now, since
OF1.1+ isn't in widespread use and those particular ports aren't
likely to be in use in OF1.1+ anyway.
- Log warnings about those ports when they are specified by number, to
allow users to fix their invocations.
Also:
- Accept the OF1.1+ port numbers for these ports, without warning, for
compatibility with the upcoming OF1.1+ support.
- Stop accepting port number 0, which has never been a valid port
number in OpenFlow 1.0 and later. (This required fixing some tests
that inadvertently used this port number).
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Simon Horman <horms@verge.net.au>
|
|
OVSDB has always had the ability to mark a column as "immutable", so that
its value cannot be changed in a given row after that row is initially
inserted. However, we discovered recently that ovsdb-server has never
enforced this constraint. This commit implements enforcement.
Reported-by: Paul Ingram <paul@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Kyle Mestery <kmestery@cisco.com>
|
|
It's not entirely clear what problem the null interface type is
trying to solve, nor how it could be of use to any controller.
This patch deprecates it, and schedules its removal for February
2013. If there are concerns, please email dev@openvswitch.org.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
|
