The "port group" concept seems like a good one, but it has not been
used very much in userspace so far, so before we commit ourselves to
a frozen API that we must maintain forever, remove it. We can always
add it back in later as a new kind of vport.
Signed-off-by: Ben Pfaff <blp@nicira.com>
The only real difference between netdev-patch and netdev-tunnel is in their
parse_config() implementation. That's a lot of extra code to maintain, for
questionable benefit. This commit merges them into the netdev-vport code,
which was heretofore merely a collection of helper functions.
Jesse pointed out that port_changed_cb isn't a great interface. It's only
around because, earlier, we had a lousy interface for monitoring netdev
status, so that we needed to pass along information obtained by ofproto
into the bridge. But netdev_monitor is now sufficiently sophisticated that
the bridge can set up an independent netdev_monitor without any important
loss of efficiency. Since this makes the code cleaner, this commit does
so.
Until now, a command that removed and added ports in a single change to
the database, e.g.:
ovs-vsctl del-port br0 vif1.0 -- add-port br0 vif2.0
typically failed, because of this sequence of events:
1. Bridge code removes vif1.0 from br0.
2. Bridge code adds vif2.0 to br0.
3. ofproto_run() receives kernel notification that vif1.0 was deleted, so
it notifies the bridge by calling back to bridge_port_changed_ofhook_cb,
which sees that it has an interface with the specified port number, and
deletes it. Oops--this is where the problem occurs. For completeness:
4. ofproto_run() receives kernel notification that vif2.0 was added, so
it notifies the bridge by calling back to ,
which sees that it has no interface with the specified port number, and
does nothing.
This commit fixes the problem by making bridge_port_changed_ofhook_cb() not
care about ports being dropped. This is a corner case that we shouldn't
work too hard to care about, since it can only happen if an administrator
is meddling with datapaths using ovs-dpctl, and the consequences are simply
that packets directed to that device will take longer to be rerouted to
another device (it will take a while for the MAC learning table to time out
the entry). Basically, the admin gets what he deserves.
Thanks to Jesse Gross for identifying the problem.
Bug #3671.
The previous commit arranged to always open the netdev for bridge ports
within the loop that adds new ports to datapaths. So now the additional
attempt to open them within the following loop is superfluous and
presumably will always fail. This commit drops it and merges two
iterations through bridge ports into a single one, since the first is now
trivial.
Until now, if the type of a bridge port changed in the database, then
ovs-vswitchd would report an error and keep it the same type. This commit
changes the behavior to something more reasonable: the old datapath port is
deleted and replaced by a new datapath port of the correct type.
iface_cfg is also available as iface->cfg, so there's no benefit in also
passing it as a separate parameter.
Also, get rid of the one-liner reconfigure_iface() function that wasn't
helping with anything.
Commit 4bee42 "tunnel: Correctly check for internal device." fixed
the call to internal_dev_get_vport() by first checking that the
device is in fact an internal device. However, it also accidentally
removed the check ensuring that the vport itself was not NULL. This
adds that check back by redoing the previous change in a more robust
manner.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
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
The CLASSIFIER_FOR_EACH_EXACT_RULE_SAFE macro was missing its "MEMBER"
argument. It doesn't currently cause any problems because no one uses
the macro.
If no controllers are specified on the command-line, ovs-openflowd adds
a couple of its own. The code that accounts for the controllers
correctly allocated space for them, but used the command-line count to
determine how many to set. This led to a segfault when later code tried
to dereference them.
Reported-by: Derek Cormier <derek.cormier@lab.ntt.co.jp>
In normal operation it makes sense to keep track of all of the flows that
have been seen recently and to cache all of them in the kernel. Under
unusual conditions, such as those caused by network scanning tools or by an
actual targeted DoS attack against the vswitch, the number of flows can
explode to extremely high numbers (hundreds of thousands or more). In such
a situation the vswitch needs to guard against memory exhaustion by
expiring flows more quickly and more often. This commit implements an
inexpensive technique for determining which flows should be dropped in such
a situation.
A wildcarded flow is idle only if all of its subrules have expired because
they were idle, so unless we expire exact-match rules first it is possible
that a wildcarded flow fails to expire as soon as it should.
(The current implementation of classifier_for_each() iterates through
exact-match rules before wildcarded rules, but nothing in the interface
guarantees that.)
This poll_immediate_wake() is unnecessary because netflow_run() is always
called afterward within the same poll loop. It's better to delete it, to
avoid wasting CPU.
In one or two corner cases, flows cannot be installed because every packet
in the flow must be processed by userspace. The code to expire rules was
ignoring these uninstallable rules, and thus they would never get freed,
even after they became idle. This commit fixes the problem.
This should be a purely stylistic change, with no effect on behavior.
This commit changes the callback pointer passed to the
classifier_for_each() from a pointer to an ofproto to a pointer to a
structure that includes an ofproto. Future commits planned will add
more members to this new structure.
GNU libc treats malloc(0) as malloc(1). Subrules always have an n_actions
of 0, so this code was wasting time and memory for subrules. This commit
stops doing that.
Also audits and fixes some very pedantic potential problems with null
pointers; e.g. the C standard says that NULL may not be compared with the
< operator, even if both arguments are null, and it also says that a null
pointer may not be passed to memcpy() or memcmp(), even if the length is
zero.
XenServer puts our header files in the standard system search path
by default. This is normally OK, except when we introduce new things
which aren't in those headers. Since the system picks up the older files
first this leads to undefined sysmbols.
Signed-off-by: Jesse Gross <jesse@nicira.com>
ovs-external-ids was crashing on startup because it was brought up
before /dev/log exists. The simplest solution to this problem is
to have it log to /var/log/openvswitch/ovs-external-ids.log . This
is consistent with vswitchd and ovsdb-server.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
With header caching we check to see if the next device in the stack
is an OVS device and, if so, cache that flow as well. However, the
test for this called internal_dev_get_vport() assuming that it would
return NULL if the device is not an internal device. It doesn't,
however, it just returns the offset from the device where the vport
data structure would be if it were an internal device. This changes
it to explicitly check for an internal device first to avoid a panic.
Bug #3470
Reported-by: Ram Jothikumar <rjothikumar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Reviewed-by: Justin Pettit <jpettit@nicira.com>
The OpenFlow OFPAT_ENQUEUE action sets a queue id and outputs the packet
in one shot. There are times in which the queue should be set, but the
output port is not yet known. This commit adds the NXAST_SET_QUEUE and
NXAST_POP_QUEUE Nicira extension actions to modify the queue
configuration without requiring a port argument.
CC: Jeremy Stribling <strib@nicira.com>
CC: Keith Amidon <keith@nicira.com>
If the netflow byte counter is UINT64_MAX, or at any rate much larger than
UINT32_MAX, netflow_expire() could loop for a very long time. This commit
avoids that case.
This is only a theoretical bug fix. I don't know of any actual bug that
would cause a counter to be that high.
This makes it a little easier to test Open vSwitch QoS features using
ovs-controller, by making it possible to assign queues on the basis of
input port, instead of just allowing a single queue for a whole switch.
CC: Michael Mao <mmao@nicira.com>
A couple of people have reported that ovs-controller --with-flows is
confusing. This seems to be because it doesn't read the file with the
flows until the first connection from a switch. Then, if the file has a
syntax error, it exits.
This commit changes the behavior so that it reads the file immediately at
startup instead.
Without this commit, "ovs-ofctl queue-stats br0 ALL 1" will print something
like the following if port 3 has queue 1 but none of the other ports do:
stats_reply (xid=0x7b378): flags=none type=5(queue)
4 queues
port 0 queue 1: bytes=?, pkts=?, errors=?
port 1 queue 1: bytes=?, pkts=?, errors=?
port 2 queue 1: bytes=?, pkts=?, errors=?
port 3 queue 1: bytes=0, pkts=0, errors=0
With this commit, it will print the following instead, which seems more
useful:
stats_reply (xid=0x3ada1): flags=none type=5(queue)
1 queues
port 3 queue 1: bytes=0, pkts=0, errors=0
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.
This macro is a variant on CONTAINER_OF that takes an object pointer
instead of a type name as its second argument. In the following commit
this will simplify many users of CONTAINER_OF.
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.
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.
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.
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.
When ovs-vsctl is not actually going to modify the database, it is less
interesting in the log, so we might as well only log it at "debug" level.
Suggested-by: Neil McKee <neil.mckee@inmon.com>
