Mike Bursell pointed out that our policer only works on IPv4
traffic--and specifically not IPv6. By using the "basic" filter, we can
enforce policing on all traffic for a particular interface.
Jamal Hadi Salim pointed out that calling "tc" directly with system() is
pretty ugly. This commit switches our remaining "tc" calls to directly
sending the appropriate netlink messages.
Suggested-by: Mike Bursell <mike.bursell@citrix.com>
Suggested-by: Jamal Hadi Salim <hadi@cyberus.ca>
netdev-linux uses netdev_linux_cache_notifier to flush its cache when the
kernel notifies userspace that a particular network device's configuration
or status has changed. This is as applicable to tap devices as to system
and internal devices, so we should create and destroy the notifier for
tap devices also.
I doubt that in practice it's possible to run ovs-vswitchd without having
a non-tap device open, at least with the kernel datapath, because the
local port for a bridge is not a tap device, so there should be no need to
backport this to older versions.
Reported-by: Gaetano Catalli <gaetano.catalli@gmail.com>
Commit 00fa9d37c2b "Do not include net/ethernet.h and linux/if_tunnel.h"
introduced a compile error on RHEL 6:
lib/netdev-linux.c: In function 'netdev_linux_listen':
lib/netdev-linux.c:734: error: 'ETH_P_ALL' undeclared (first use in this
function)
This fixes the problem.
I verified that the Android NDK r6b mentioned in the previous commit
contains a file named android-ndk-r6b/platforms/android-3/arch-x86/use/
linux/if_ether.h that defines ETH_P_ALL. I didn't try building on that
platform.
netdev_find_dev_by_in4() appears to no longer be used and thus
can be removed. This also allows netdev_enumerate(), the
enumerate member of struct netdev_class and netdev_linux_enumerate()
to be removed.
I noticed this as netdev_linux_enumerate() makes use of if_nameindex()
and if_freenameindex() which are not available when compiling using
the Android NDK r6b (Android API level 13).
net/ethernet.h and linux/if_tunnel.h do not appear to be needed
on lib/netdev-linux.c.
I noticed this while trying to build on the Android NDK r6b (Android API
level 13) as these headers are not present there.
This patch changes the interface of netlink-notifier and
rtnetlink-link. Now nln_notifiers are allocated and destroyed by
the module instead of passed in by callers. This allows the
definition of nln_notifier to be hidden, and generally cleans up
the code.
It makes more sense to call nln_notifier_run() and
nln_notifier_wait() simply nln_run() and nln_wait() since they
don't operate on notifiers but the entire nln object. This patch
changes the nln and the rtnetlink-link modules to the new
convention.
Currently ovs is using device stats for Linux devices and count them
itself in other situations. This leads to overlap with hardware stats,
inconsistencies, etc. It's much better to just always count the packets
flowing through the switch and let userspace do any merging that it wants.
Following patch removes vport->get_stats() interface. vport-stat is changed
to use new `struct ovs_vport_stat` rather than rtnl_link_stats64.
Definitions of rtnl_link_stats64 is removed from OVS. dipf_port->stat is also
removed as aggregate stats are only available at netdev layer.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
There is no need to have vport attribute MTU (OVS_VPORT_ATTR_MTU) as
linux net-dev-ioctl can be used to get/set MTU for linux device.
Following patch removes OVS_VPORT_ATTR_MTU from datapath protocol.
This patch also adds netdev_set_mtu interface. So that MTU adjustments
can be done from OVS userspace. get_mtu() interface is also changed, now
get_mtu() returns EOPNOTSUPP rather than returning 0 and setting *pmtu
to INT_MAX in case there is no MTU attribute for given device.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
This patch renames the rtnetlink module's code to "nln" for
"netlink notifier". Callers are now required to pass in the
netlink protocol to he newly renamed nln_create() function.
The only rtnetlink specific functionality contained in the
rtnetlink module is the use of the NETLINK_ROUTE protocol. This
can easily be passed in by callers.
In preparation for generalization, this patch renames
rtnetlink.[ch] to netlink-notifier.[ch]. Future patches will
complete the transition.
Until now, each call to netdev_open() for a particular network device
had to either specify a set of network device arguments that was either
empty or (for devices that already existed) equal to the existing device's
configuration. Unfortunately, the definition of "equality" in the latter
case was mostly done in terms of strict equality of string-to-string maps,
which caused problems in cases where, for example, one set of arguments
specified the default value of an optional argument explicitly and the
other omitted it.
The netdev interface does have provisions for defining equality other ways,
but this had only been done in one case that was especially problematic in
practice. One way to solve this particular problem would be to carefully
define equality in all the problematic cases.
This commit takes another approach based on the realization that there is
really no need to do any comparisons. Instead, it removes configuration
at netdev_open() time entirely, because almost all of netdev_open()'s
callers are not interested in creating and configuring a netdev. Most of
them just want to open a configured device and use it. Therefore, this
commit stops providing any configuration arguments to netdev_open() and the
provider functions that it calls. Instead, a caller that does want to
configure a device does so after it opens it, by calling
netdev_set_config().
This change allows us to simplify the netdev interface a bit. There is no
longer any need to implement argument comparisons. As a result, there is
also no need for "struct netdev_dev" to keep track of configuration at all.
Instead, the network devices that have configuration keep track of it in
their own internal form.
This new interface does mean that it becomes possible to accidentally
create and try to use an unconfigured netdev that requires configuration.
Bug #6677.
Reported-by: Paul Ingram <paul@nicira.com>
The Open vSwitch tree only has one user of the ability for a netdev to
receive packets from a network device. Thus, this commit simplifies the
common-case use of the netdev interface by replacing the "ethertype" option
from "struct netdev_options" by a new netdev_listen() call.
The only user of netdev_listen() wants to receive all packets from a
network device, so this commit also removes the ability to restrict the
received packets to a particular protocol. (This ability was once used by
the Open vSwitch integrated DHCP client, but that code has been removed.)
This commit also simplifies and improves the implementation of the code
in netdev-linux that started listening to a network device. Before, I had
not figured out how to avoid receiving all packets on all devices before
binding to a particular device, but I took a closer look at the kernel code
and figured it out.
I've tested that the userspace datapath (dpif-netdev), the only user of
netdev_recv(), still works after this change.
Bug #5844 reports several log messages of the form:
netdev_linux|ERR|ioctl(SIOCGIFHWADDR) on vif426.1 device failed: No
such device
during migrations. These are normal and unavoidable, because the vifs
disappear from the kernel before they are removed them from the OVS
database. Reduce the log level to avoid making people worry.
Bug #5844.
When doing a netdev_open(), a check is first done to make sure the
arguments are equivalent for any open devices with the same name. In
most cases, a simple shash comparison is sufficient. However, IPsec
key configuration is handled by an external program, so it is not pushed
down into the kernel module. Thus, when the "unparse_config" method is
called on an existing IPsec-based vport, a simple comparison with the
returned data will not match the original configuration. This commit
adds code to allow netdev-specific argument comparisons and has
"ipsec_gre" make use of them.
Bug #5575
This patch moves miimon logic from the bond module to netdev-linux.
This greatly simplifies the bonding code while adding minimal
complexity to netdev-linux. The bonding code is so high level, it
really has no business worrying about how precisely slave status is
determined.
I know already that this breaks the statsfixes that were implemented by the
following commits:
827ab71c97f "ofproto: Datapath statistics accounted twice."
6f1435fc8f7 "ofproto: Resubmit statistics improperly account during..."
These were already broken in a previous merge. I will work on a fix.
With this commit, the tree compiles clean with sparse commit 87f4a7fda3d
"Teach 'already_tokenized()' to use the stream name hash table" with patch
"evaluate: Allow sizeof(_Bool) to succeed" available at
http://permalink.gmane.org/gmane.comp.parsers.sparse/2461 applied, as long
as the "include/sparse" directory is included for use by sparse (only),
e.g.:
make CC="CHECK='sparse -I../include/sparse' cgcc"
I looked at almost every uint<N>_t in the tree to determine whether it was
really in network byte order, and converted the ones that were.
The only remaining ones, modulo my mistakes, are in openflow.h. I'm not
sure whether we should convert those, because there might be some value
in remaining close to upstream for this header.
rtnl_link_stats64 has rx_compressed and tx_compressed members that
struct netdev_stats lacks, so we need to initialize them to zero when
converting.
Found by valgrind.
Only a privileged process can open a raw AF_PACKET socket, so netdev-linux
will fail to initialize if run as non-root and you get a cascade of error
messages, like this:
netdev_linux|ERR|failed to create packet socket: Operation not permitted
netdev|ERR|failed to initialize system network device class: Operation not permitted
netdev|ERR|failed to initialize internal network device class: Operation not permitted
netdev|ERR|failed to initialize tap network device class: Operation not permitted
But in fact the AF_PACKET socket is not needed for most operations (only
for sending packets) and it is never needed for testing with the "dummy"
datapath and network device, so we can avoid logging all of these errors
by opening the packet socket only on demand, as this commit does.
Reviewed-by: Simon Horman <horms@verge.net.au>
I looked at almost every uint<N>_t in the tree to determine whether it was
really in network byte order, and converted the ones that were.
The only remaining ones, modulo my mistakes, are in openflow.h. I'm not
sure whether we should convert those, because there might be some value
in remaining close to upstream for this header.
An upcoming commit will introduce another function that needs to convert
between rtnl_link_stats64 and netdev_stats, so it seemed best to just add
functions to do the conversion.
Commit 76c308b50d3 "netdev-linux: Support 'send' for netdevs opened with
NETDEV_ETH_TYPE_NONE" broke sending packets to tap devices. Sending a
packet to a tap device with an AF_PACKET socket causes that packet to be
looped back to be received on the tap device again, which obviously isn't
useful.
Obviously correct code is easier on everyone. As the C FAQ says:
20.15c: How can I swap two values without using a temporary?
A: The standard hoary old assembly language programmer's trick is:
a ^= b;
b ^= a;
a ^= b;
But this sort of code has little place in modern, HLL
programming. Temporary variables are essentially free,
and the idiomatic code using three assignments, namely
int t = a;
a = b;
b = t;
is not only clearer to the human reader, it is more likely to be
recognized by the compiler and turned into the most-efficient
code (e.g. using a swap instruction, if available). The latter
code is obviously also amenable to use with pointers and
floating-point values, unlike the XOR trick. See also questions
3.3b and 10.3.
There doesn't appear to be any reason to enforce a minimum min-rate
of 1500Bps on queues. This commit lowers the minimum to 1Bps. A
min-rate of 0 is not allowed by hfsc in the kernel.
One could quite reasonably desire to create a queue with no
min-rate. For example, a default queue could be reasonably
configured without a min-rate or a max-rate. This commit removes
the requirement that min-rate be configured on all queues. If not
configured, defaults to something very small.
Coverity complains that we're copying the unitialized "sin_zero" member
from "sin" into "r". I don't think this is an actual problem, but
there's no harm in zeroing out the structure, either.
Coverity #10916
Static analyzers hate strncpy(). This new function shares its property of
initializing an entire buffer, without its nasty habit of failing to
null-terminate long strings.
Coverity #10697,10696,10695,10694,10693,10692,10691,10690.
Until now, tunnel vports have had a specific MTU, in the same way that
ordinary network devices have an MTU, but treating them this way does not
always make sense. For example, consider a datapath that has three ports:
the local port, a GRE tunnel to another host, and a physical port. If
the physical port is configured with a jumbo MTU, it should be possible to
send jumbo packets across the tunnel: the tunnel can do fragmentation or
the physical port traversed by the tunnel might have a jumbo MTU.
However, until now, tunnels always had a 1500-byte MTU by default. It
could be adjusted using ODP_VPORT_MTU_SET, but nothing actually did this.
One alternative would be to make ovs-vswitchd able to set the vport's MTU.
This commit, however, takes a different approach, of dropping the concept
of MTU entirely for tunnel vports. This also solves the problem described
above, without making any additional work for anyone.
I tested that, without this change, I could not send 1600-byte "pings"
between two machines whose NICs had 2000-byte MTUs that were connected to
vswitches that were in turn connected over GRE tunnels with the default
1500-byte MTU. With this change, it worked OK, regardless of the MTU of
the network traversed by the GRE tunnel.
This patch also makes "patch" ports MTU-less.
It might make sense to remove vport_set_mtu() and the associated callback
now, since ordinary network devices are the only vports that support it
now.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Suggested-by: Jesse Gross <jesse@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Bug #3728.
This gives network device implementations the opportunity to fetch an
existing device's configuration and store it as their arguments, so that
netdev clients can find out how an existing device is configured.
So far netdev-vport is the only implementation that needs to use this.
The next commit will add use by clients.
Reviewed by Justin Pettit.
I introduced this a long time ago as an efficient way for userspace to find
out whether and where an internal device was attached, but I've always
considered it an ugly kluge. Now that ODP_VPORT_QUERY can fetch a vport's
info regardless of datapath, it is no longer necessary. This commit
stops using Ethtool for this purpose and drops the feature.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
When this library was originally implemented, support for Linux 2.4 was
important. The Netlink implementation in Linux only added support for
joining and leaving multicast groups after a socket is bound as of Linux
2.6.14, so the library did not support it either. But the current version
of Open vSwitch targets Linux 2.6.18 and over, so it's fine to add this
support now, and this commit does so.
This will be used more extensively in upcoming commits.
Reviewed by Justin Pettit.
New columns in Interface table: admin_state, link_state, link_speed, duplex,
mtu.
New keys in status map in Interface table: driver_name, driver_version,
firmware_version.
Requested-by: Peter Balland <pballand@nicira.com>
Bug #4299.
