For some time now, Open vSwitch datapaths have internally made a
distinction between adding a vport and attaching it to a datapath. Adding
a vport just means to create it, as an entity detached from any datapath.
Attaching it gives it a port number and a datapath. Similarly, a vport
could be detached and deleted separately.
After some study, I think I understand why this distinction exists. It is
because ovs-vswitchd tries to open all the datapath ports before it tries
to create them. However, changing it to create them before it tries to
open them is not difficult, so this commit does this.
The bulk of this commit, however, changes the datapath interface to one
that always creates a vport and attaches it to a datapath in a single step,
and similarly detaches a vport and deletes it in a single step.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Until now, the collection of coverage counters supported by a given OVS
program was not specific to that program. That means that, for example,
even though ovs-dpctl does not have anything to do with mac_learning, it
still has a coverage counter for it. This is confusing, at best.
This commit fixes the problem on some systems, in particular on ones that
use GCC and the GNU linker. It uses the feature of the GNU linker
described in its manual as:
If an orphaned section's name is representable as a C identifier then
the linker will automatically see PROVIDE two symbols: __start_SECNAME
and __end_SECNAME, where SECNAME is the name of the section. These
indicate the start address and end address of the orphaned section
respectively.
Systems that don't support these features retain the earlier behavior.
This commit also fixes the annoyance that files that include coverage
counters must be listed on COVERAGE_FILES in lib/automake.mk.
This commit also fixes the annoyance that modifying any source file that
includes a coverage counter caused all programs that link against
libopenvswitch.a to relink, even programs that the source file was not
linked into. For example, modifying ofproto/ofproto.c (which includes
coverage counters) caused tests/test-aes128 to relink, even though
test-aes128 does not link again ofproto.o.
A few coverage counters were incremented both in netdev generic code and
in netdev_linux code. This commit drops the increments from the
lower-level code.
(This is not an actual bug because these counters are used only for
logging.)
This commit implements the Hierarchical Fair Service Curve queuing
discipline in linux. HFSC performs better at high bandwidth and
implements min-rate proportional sharing of excess bandwidth. Only
a simplified configuration interface is exposed to the user. This
can be expand to allow more tweaking in the future.
This patch defines, by convention, queue 0 as the default queue in
a particular QOS. Thus, if queue 0 is defined, all traffic going
through the relevant interface will be enqueued in it. If queue 0
is not defined then ovs will send the traffic directly through the
interface without applying any policy to it.
A "min-rate" of zero for the "linux-htb" QoS type would cause a divide
by zero exception. This patch prevents that by just returning zero. A
later patch will try to enforce reasonable values for "min-rate".
Bug #3745
Linux kernel queue numbers are one greater than OpenFlow queue numbers, for
HTB anyhow. The code to dump queues wasn't compensating for this, so this
commit fixes it up.
The main advantage of a sparse array over a hash table is that it can be
iterated in numerical order. But the OVS implementation of sparse arrays
is quite expensive in terms of memory: on a 32-bit system, a sparse array
with exactly 1 nonnull element has 512 bytes of overhead. In this case,
the sparse array's property of iteration in numerical order is not
important, so this commit converts it to a hash table to save memory.
All of these changes avoid using the same name for two local variables
within a same function. None of them are actual bugs as far as I can tell,
but any of them could be confusing to the casual reader.
The one in lib/ovsdb-idl.c is particularly brilliant: inner and outer
loops both using (different) variables named 'i'.
Found with GCC -Wshadow.
Much of the code in the GRE implementation is not specific to the
GRE protocol but is actually common to all types of tunnels. In
order to support future types of tunnels, move this code into a
common library.
Signed-off-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.
Linux traffic control handles with minor number 0 refer to qdiscs, not
to classes. This commit deals with this by using a conversion function:
OpenFlow queue 0 maps to minor 1, queue 1 to minor 2, and so on.
A netdev-linux traffic control implementation has to dump all of a port's
traffic classes in a couple of different situations. start_queue_dump()
is supposed to do that. But it was specifying TC_H_ROOT as tcm_parent,
which only dumped classes that were direct children of the root. This
commit changes tcm_parent to 0, which obtains all traffic classes
regardless of parent.
ovs-vswitchd doesn't declare its QoS capabilities in the database yet,
so the controller has to know what they are. We can add that later.
The linux-htb QoS class has been tested to the extent that I can see that
it sets up the queues I expect when I run "tc qdisc show" and "tc class
show". I haven't tested that the effects on flows are what we expect them
to be. I am sure that there will be problems in that area that we will
have to fix.
This simplifies a bit of existing code since it is known that an rtnetlink
socket will always be available. It will simplify additional code in
upcoming commits.
These two functions use their "sock" parameter only to figure out the
nlmsg_pid to put in the nlmsghdr. But that field can be filled in just
as well right before sending the message. Since our functions for sending
Netlink messages always modify the nlmsghdr anyhow (to fill in the length),
there is little benefit to filling in the nlmsg_pid in advance. The cost,
on the other hand, is having to pass another argument to functions that
already have too many. So this commit removes the argument.
In certain cases we require the ability to provide stats that are
added to the values collected by the kernel (currently only used
by bond fake devices). Internal devices previously implemented
this directly but now that their stats are now handled by the vport
layer the functionality has been moved there. This removes the
userspace code to set the stats and replaces it with a mechanism
to access the equivalent functionality in the vport layer.
The vport layer has the ability to track stats using 64-bit counters,
even if the kernel is only 32-bit. This first attempts to collect
stats from these counters if they are available and otherwise falls
back to the normal Linux interfaces.
Tap devices can have two FDs that allow transmit and receive from
different perspectives. We previously would always share one of
the FDs among all openers. However, this is confusing to some
users (primarily the DHCP client) which expect tap devices to behave
like any other device. Now we give the tap FD to the first opener,
which knows that it has opened a tap device, and a normal system FD
to everyone else for consistency.
For tap and internal devices we swap the transmit and receive stats
to appear consistent with other devices. However, the check whether
to store the stats in a temporary location before the swap did not
include tap devices, which lead to the use of uninitialized memory
when the swap occured.
If we attempt to remove ingress policing and receive "invalid
argument" it means that policing isn't compiled into the kernel.
If it isn't compiled in then accept that policing has been
successfully removed.
Now that we have a new patch implementation, remove the veth driver
and its userspace components. Then rename 'patchnew' to 'patch'.
The new implementation is a drop-in replacement for the old one.
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.
The new GRE implementation provides a complete drop in replacement
for the old Linux based implementation. Therefore, remove the
old implementation and rename "grenew" to "gre".
We allocate struct netdev_linux which contains struct netdev but
free the netdev. In practice this makes no difference because the
netdev is the first member of the struct but we should be correct
anyways.
When receiving a change notification from rtnetlink we checked whether
a netdev of that name existed and if so tried to handle it. This also
checks that the type of the device is one handled by netdev-linux.
This commit introduces a new netdev type called "patch". A patch is a
pair of interfaces, in which frames sent through one of the devices
pop out of the other. This is useful for linking together datapaths.
A patch's only argument on creation is "peer", which specifies the other
side of the patch. A patch must be created in pairs, so a second netdev
must be created with the "name" and "peer" values reversed.
The current implementation is built using veth devices. Further, it's
limited to the veth devices which support configuration through sysfs.
This limits the ability to use a "patch" on 2.6.18 kernels using the
veth device we include (read: flavors of XenServer 5.5). In the not too
distant future, the implementation will be modified to use the new
kernel port abstraction introduced by Jesse Gross's forthcoming GRE
work. At that point, patch devices will work on any Linux platform
supported by OVS.
This allows path MTU discovery to properly work when used with
bridging. While there was previously support for PMTUD it used
the kernel's IP stack. This works fine for routing but when
bridging it is possible that a complete network is operating over
the bridge that the kernel has no knowledge of and the ICMP
fragmentation needed packets are lost.
When a packet arrives that is above the MTU of the tunnel, an
ICMP message is synthesized and send back on the device that the
original packet came from. This does not rely on the kernel IP
stack and is therefore independent of the routing table. Both
IPv4 and IPv6 are supported, including over VLANs. Other types
of packets that are over the MTU are encapsulated and the outer
packets are fragmented.
This entire functionality is a layer violation since bridging
operates at layer 2 and fragmentation is a function of layer 3.
For this reason it is possible to disable PMTUD, which will
provide complete transparency but will cause the outer IP packets
to be fragmented.
Currently the TTL is copied from the inner packet of the tunnel to
the outer packet if the inner packet is IP. This is good if your
GRE packets might make it into the input of your device but bad
if you want to be fully transparent.
This also resolves an inconsistency between tunnels set up using
the ioctl and using Netlink. The ioctl version would force PMTUD
on if a fixed TTL is set as a backup way to prevent loops but it
never made it over to the newer Netlink code so obviously no one
cares too much about it. This removes it to provide consistency
and transparency.
Basically, don't create loops and you will be happy.
If we are using netlink to get stats and get_ifindex() fails, then for
an internal network device we will then swap around a bunch of
indeterminate (uninitialized) data values. That won't hurt anything--the
caller will still set them to all-1-bits due to the error--but it still
seems wrong. So this commit avoid it.
Found using Clang (http://clang-analyzer.llvm.org/).
We previously maintained a list of open devices inside of the
linux netdev. Since the netdev library now maintains this list,
it is better to use that list instead of our own.
Never close the file descriptor if it is 0, since it is never a
valid FD in this context. Also initialize the FD to -1 so that
it is never set to a valid but incorrect value.
We were storing a struct netdev_dev_linux ** instead of a
netdev_dev_linux * in the cache map. This prevented the cache
from being invalidated on changes such as link status.
The default burst rate was 10Kb. This increases it to 1000kb, since
we were having problems getting traffic through at 10kb. A better value
probably exists between these two points, but that will require
additional experimentation.
Calling close(0) at random points is bad. It means that the next call to
socket() or open() returns fd 0. Then the next time a netdev gets closed,
that socket or file fd gets closed too, and you end up with weird "Bad
file descriptor" errors.
Found by installing the following as lib/unistd.h in the source tree:
#ifndef UNISTD_H
#define UNISTD_H 1
#include <stdlib.h>
#include_next <unistd.h>
#undef close
#define close(fd) rpl_close(fd)
static inline int rpl_close(int fd)
{
if (!fd) {
abort();
}
return (close)(fd);
}
#endif
TAP devices need to be treated slightly differently from other other
devices because they cannot be opened multiple times. Instead we
open them once and share the file descriptor. This means that if
the netdev is opened multiple times one reader can drain the buffers
of another. While this is a deviation from the normal convention,
it does not impact current or planned users.
In addition, this cleans up some confusion between the file
descriptor for tap devices versus other FD's.
