do_flowvec_ioctl() was checking for too-big 'n_flows' but not negative
'n_flows'. We could add that check too, but 'n_flows' should never be
negative so it's better to just use an unsigned type.
If a monitored daemon dies quickly at startup, the system can waste a lot
of CPU time continually restarting it. This commit prevents a given
daemon from restarting more than once every 10 seconds.
If the monitored daemon dumps core frequently, then this can quickly
exhaust the host's disk space. This commit limits core dumps to at most
one per monitored session (typically, once per boot).
This makes "ovs-ofctl snoop" and anything else that connects to the
switch's "snoop" socket typically more useful in the presence of multiple
controllers, since the "master" connection is the one with the most
interesting traffic.
Suggested-by: Justin Pettit <jpettit@nicira.com>
When ofproto_sflow_set_options() fails, it calls ofproto_sflow_clear() to
deconfigure the ofproto_sflow object. But ofproto_sflow_clear() deletes
all of the object's record of datapath ports. That means that the next
call to ofproto_sflow_set_options(), if it succeeds, will believe that the
datapath has no ports.
This commit fixes the problem by only clearing ofproto_sflow's record of
datapath ports when it is destroyed, not just when a configuration error
occurs.
Reported-by: Neil McKee <neil.mckee@inmon.com>
The "snoop" command does roughly the same thing as "monitor", but it is
easier to use in the common case where one just wants to look at the
OpenFlow controller connection for a bridge. Instead of, for example,
ovs-ofctl monitor unix:/var/run/openvswitch/br0.snoop
one merely types
ovs-ofctl snoop br0
ofproto supports listening for "transient connections" from clients such
as ovs-ofctl. These OpenFlow connections are not supposed to receive
asynchronous messages by default, unless they ask for them by setting an
nonzero packet-in send length. This feature got broken some time back.
This commit fixes it.
Sometimes, when a user asks me to help debug a problem, it turns out that
an SSL connection was being made on a TCP port, or vice versa, or that an
OpenFlow connection was being made on a JSON-RPC port, or vice versa, and
so on. This commit adds log messages that diagnose this kind of problem,
e.g. "tcp:127.0.0.1:6633: received JSON-RPC data on OpenFlow channel".
We throw away packets that are received on vports not attached to
a datapath but we are actually leaking them. This records that an
error took place and frees the skb.
Normally match fields are zeroed if they are wildcarded in
normalize_match(). However, tun_id isn't part of struct ofp_match
so do it when we convert to a flow instead.
When creating an interface we need to check whether it is internal.
However, the function iface_is_internal() does a lookup on the
interface name but we haven't added it to the hash table yet. This
adds the interface to the table early on in iface_create.
NIC-78
I had been under the impression that "memcpy" was a valid way to copy
unaligned data into an aligned location for access. But testing on SPARC
has shown that GCC doesn't always honor that intention. It seems that, if
GCC can see that there is a pointer of a type that requires alignment to
a given object, then it will access it directly regardless of whether
memcpy() is used to copy it.
This commit adds a new header with functions to access unaligned data. I
managed to come up with two techniques, one GCC-specific, one generic, that
do avoid the misaligned access in my test case. The GCC-specific technique
is the same one used by the Linux kernel (although no code has been
literally copied). The other one seemed obvious but possibly slow
depending on the compiler's ability to optimize.
The following commit adds a user.
The "monitor" command goes to some trouble to write its output in a
predictable order, so that test programs can reliably compare it against
expectations. This commit fixes up one part that was missing, which is
that the columns were not being ordered predictably (it depended on
hash order, which differs between big-endian and little-endian systems).
It also updates the test suite to expect the new order.
This test examines the OVSDB database log and checks that it contains what
it should for specified transactions. However, the database log ordering
differs between big-endian and little-endian architectures because it is
written out in hash order. We don't want to incur the expense of always
sorting the log as we write it out, so instead this commit fixes the
problem by sorting the log as it reads it, using the "test-json" program.
One part of the "weak references" test inserts invalid all-zeros weak
references into two columns and expects to get an error message mentioning
one of them. Unfortunately the one that actually gets mentioned depends
on hash ordering and thus differs between big-endian and little-endian
machines. This commit fixes the problem by only putting an invalid
reference in a single column, instead of two of them.
The formatting of OVSDB syntax errors differed between big-endian and
little-endian systems, which caused the "database multiplexing
implementation" test to fail on SPARC. This commit fixes the problem by
always outputting JSON in syntax errors in deterministic (sorted) order.
On sparc, GCC would issue the following warning for every use of
CONTAINER_OF:
warning: cast increases required alignment of target type
This is a false positive: assuming that the data structure that it is
applied to was allocated properly, the use of CONTAINER_OF to reach it is
valid. And if it was not allocated properly, then code that accesses it
other ways will have trouble too.
Enables checksum offloading, scatter/gather, and TSO on internal
devices. While these optimizations were not previously enabled on
internal ports we already could receive these types of packets from
Xen guests. This has the obvious performance benefits when these
packets can be passed directly to hardware.
There is also a more subtle benefit for GRE on Xen. GRE packets
pass through OVS twice - once before encapsulation and once after
encapsulation, moving through an internal device in the process.
If it is a SG packet (as is common on Xen), a copy was necessary
to linearize for the internal device. However, Xen uses the
memory allocator to track packets so when the original packet is
freed after the copy netback notifies the guest that the packet
has been sent, despite the fact that it is actually sitting in the
transmit queue. The guest then sends packets as fast as the CPU
can handle, overflowing the transmit queue. By enabling SG on
the internal device, we avoid the copy and keep the accounting
correct.
In certain circumstances this patch can decrease performance for
TCP. TCP has its own mechanism for tracking in-flight packets
and therefore does not benefit from the corrected socket accounting.
However, certain NICs do not like SG when it is not being used for
TSO (these packets can no longer be handled by TSO after GRE
encapsulation). These NICs presumably enable SG even though they
can't handle it well because TSO requires SG.
Tested controllers (all 1G):
Marvell 88E8053 (large performance hit)
Broadcom BCM5721 (small performance hit)
Intel 82571EB (no change)
It seems that dev_disable_lro() and skb_warn_if_lro() are not always
defined at the same time, despite the fact that they are typically
used together. This independently tests for them.
OpenFlow provides the ability to delete flows that match a "strict"
description. This means that wildcards are not active, and thus will
only match a single flow that exactly matches the description. The code
that checks for a match is pretty dumb and still compares the values of
fields that are wildcarded. A recent change added a "tun_id" matching
field, but did not zero out the field when it was supposed to be
ignored, which broke the matching used by strict deletions. This sets
the field regardless of whether the field is wildcarded or not.
Reported-by: Natasha Gude <natasha@nicira.com>
Bug #2775
The "max_len" feature of ofp_action_output is completely unimplemented
currently. Implement it.
Reported-by: Tetsuo NAKAGAWA <nakagawa@mxc.nes.nec.co.jp>
It is very expensive to start a subprocess and, especially, to wait for it
to complete. This replaces the most common subprocess operation in
netdev_linux_set_policing() by a Netlink socket operation, which is much
faster.
Without this and the other netdev-linux commits, my 1000-interface test
case runs in 1 min 48 s. With them, it runs in 25 seconds.
Profiling with qprof showed that bitmap_set_multiple() and bitmap_equal()
were eating up quite a bit of CPU time during bridge reconfiguration (up
to about 10% of total runtime). This is completely avoidable in the common
case where a port trunks all VLANs, where we don't really need a bitmap at
all. This commit implements that optimization.
Before this commit and the preceding one, with 1000 interfaces strcmp()
took 36% and port_lookup() took 8% of total runtime when reconfiguring
bridges. With these two commits the percentage is reduced to 3% and 0%,
respectively.
Before this commit and the following one, with 1000 interfaces strcmp()
took 36% and port_lookup() took 8% of total runtime when reconfiguring
bridges. With these two commits the percentage is reduced to 3% and 0%,
respectively.
This is useful for profiling, since common profilers do not print anything
until the process terminates, and only if the process terminates in the
ordinary way by calling exit().
he ofproto_sflow_add_poller() and ofproto_sflow_add_sampler() calls
should always be made together, either when a port is added
dynamically with ofproto_sflow_add_port() or when the sflow_agent is
first created in ofproto_sflow_set_options(). I was seeing odd
behavior where either the pollers or the samplers would never be
instantiated depending on the order that things happened. (It's OK to
add the same sampler or poller again, because the library routines
sfl_agent_addPoller() and sfl_agent_addSampler() will just return the
existing one if it is there. Perhaps we should add a comment to make
that clear?).
I changed the parameters to ofproto_sflow_add_sampler to make it work
the same way as ofproto_sflow_add_poller, where the options are
extracted from os->options within the function itself.
When /etc/xensource/network.conf contains the word "bridge", the system
is supposed to use the Linux bridge, not Open vSwitch. This commit makes
OVS honor this setting, which until now it has mainly ignored.
Reported-by: Reid Price <reid@nicira.com>
XAPI updates the pool.conf file before it actually refreshes its database
from the new pool, so we need to wait for that to happen. Hard-coded
delays aren't a good idea, but in the long term XAPI will probably be
adding a hook script for us to use, so this may be an OK stopgap measure.
Bug #2756.
