| Age | Commit message (Collapse) | Author |
|---|
|
OVS needs to inspect the headers in the kernel source directory at build
time. Debian keeps moving the source directory relative to the build
directory and doesn't provide an obvious way to find the source directory,
so in the past we've used some name-based heuristics to essentially guess
where it is.
This commit introduces a new heuristic that I hope will be more reliable:
extracting the source directory from the Makefile in the build directory.
In Debian's case, it looks like the Makefile generally contains a line of
the form "MAKEARGS := -C <srcdir> O=<outdir>". This commit extracts the
source directory from that line.
To avoid regressions this commit retains the older heuristics as fallbacks.
CC: 659685@bugs.debian.org
Reported-by: Thomas Goirand <zigo@debian.org>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
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>
|
|
The "cgcc" script included with sparse guesses the target architecture
based on the host architecture instead of based on the GCC architecture.
This means that it often guesses wrong on biarch systems, e.g. my Linux
kernel is x86_64 but userspace is i686 and thus GCC targets i686 by
default.
This fixes the problem by passing an explicit "-target=i86" to cgcc if
GCC targets x86 or "-target=x86_64" if GCC targets x86_64.
Bug #6312.
Reported-by: Ethan Jackson <ethan@nicira.com>
|
|
The linux-2.6 and compat-2.6 directories apply equally to the upcoming
Linux 3.0 release, so this drops the 2.6 suffix and updates Makefiles.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
|
|
|
When "configure"'s environment contains KSRC, "configure" would use it in
preference to the value specified on --with-linux. This caused a problem
for module-assistant builds in particular.
|
|
Until now, the configure script has rejected any version of Linux other
than 2.6. In preparation for Linux 3.0, this allows newer versions also.
|
|
Linux 3.0 will be out soon, so it seems like a good idea to reflect that
in our "configure" script options.
|
|
OVS used to support Linux 2.4 and Linux 2.6, but now it only supports
Linux 2.6. Linux 3.0 is coming up, and it's just an evolution of 2.6, so
OVS should stop referring to it as "2.6".
This takes a first step by removing "26" from internal variable names.
There should be no user-visible changes.
|
|
|
|
Kernels before 2.6.30 did not implement consume_skb() although RHEL
backports it. For other kernels, this provides a backport.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
|
The C=1 convention matches the kernel's convention, so running "make C=1"
will now get sparse results for both userspace and kernel compiles.
|
|
-Werror is useful for development, but it screws up configure because it's
impossible to guess what new warnings compilers will add in the future.
This commit adds a new configure option to add CFLAGS after the configure
checks are done.
The use of AC_CONFIG_COMMANDS_PRE is based on Eric Blake's suggestion on
the autoconf mailing list: "AC_CONFIG_COMMANDS_PRE probably fits the bill
as the ideal macro to use for guaranteeing that you inject your shell code
at the last possible moment."
Requested-by: Andrew Evans <aevans@nicira.com>
|
|
Some Linux network drivers support a feature called "VLAN acceleration",
associated with a data structure called a "vlan_group". A vlan_group is,
abstractly, a dictionary that maps from a VLAN ID (in the range 0...4095)
to a VLAN device, that is, a Linux network device associated with a
particular VLAN, e.g. "eth0.9" for VLAN 9 on eth0.
Some drivers that support VLAN acceleration have bugs that fall roughly
into the following categories:
* Some NICs strip VLAN tags on receive if no vlan_group is registered,
so that the tag is completely lost.
* Some drivers size their receive buffers based on whether a vlan_group
is enabled, meaning that a maximum size packet with a VLAN tag will
not fit if a vlan_group is not configured.
* On transmit some drivers expect that VLAN acceleration will be used
if it is available (which can only be done if a vlan_group is
configured). In these cases, the driver may fail to parse the packet
and correctly setup checksum offloading and/or TSO.
The correct long term solution is to fix these driver bugs. To cope until
then, we have prepared a patch to the Linux kernel network stack that works
around these problems. This commit adds support for the workaround
implemented by that patch.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
|
|
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
|
Suggested-by: Andrew Evans <aevans@nicira.com>
|
|
New versions of Xen backport this function.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
|
Red Hat Enterprise Linux 6 has a 2.6.32 kernel but it backports the
rtnl_link_stats64 structure that was introduced in 2.6.35, so we need to
check whether it was defined instead of just guessing based on the kernel
version number.
Build-tested only, on 2.6.32-71.14.1.el6 (RHEL 6),
linux-2.6.18-128.1.6.el5.xs5.5.0.496.101 (XenServer 5.5.0),
2.6.18-128.1.6.el5.xs5.5.0.505.1024xen (XenServer 5.5.0 update 1),
and upstream 2.6.18, 2.6.26, 2.6.29, 2.6.33, 2.6.34, 2.6.36, all for i386,
plus 2.6.36 for x86-64.
My machine's userspace headers have <linux/if_link.h> but not
rtnl_link_stats64. Jesse Gross tested the case where <linux/if_link.h>
has rtnl_link_stats64, on Ubuntu 10.10.
Reported-by: Geoff White <gwhite@nicira.com>
Tested-by: Jesse Gross <jesse@nicira.com>
|
|
Provides ability to match over IPv6 traffic in the same manner as IPv4.
Currently, the matching fields include:
- IPv6 source and destination addresses (ipv6_src and ipv6_dst)
- Traffic Class (nw_tos)
- Next Header (nw_proto)
- ICMPv6 Type and Code (icmp_type and icmp_code)
- TCP and UDP Ports over IPv6 (tp_src and tp_dst)
When defining IPv6 rules, the Nicira Extensible Match (NXM) extension to
OVS must be used.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
|
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
|
|
Reported-by: Koichi Yagishita <yagishita.koichi@jrc.co.jp>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
|
Most users of OVS_GREP_IFELSE simply defined HAVE_<regex>, so make this
the default.
|
|
We now test that a file exists before grepping but that doesn't
work if there are multiple possible files. For the one case that
needs this (kmemdup) break the test into two: check the first file
and if the pattern isn't found check the second file.
|
|
Certain versions of XenServer add debugging to csum_and_copy_to_user()
in such a way that it changes the function signature. This adds a
check and a workaround to allow us to build on these versions.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
|
Currently we die when grepping for compatibility strings if the
file does not exist. Since this can be a valid situation when
files are added in later versions, we shouldn't kill the build.
Instead, note that the file doesn't exist but otherwise treat it
as if the string was not found.
|
|
Reported-by: Alexey I. Froloff <raorn@altlinux.org>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
|
|
We don't actually use this function anymore so there isn't a
point in having a configure test for it.
|
|
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
|
|
OVS can usually find the kernel source itself, but when it can't it's
handy if the user can just specify it on the "configure" command line.
Signed-off-by: Ian Campbell <Ian.Campbell@citrix.com>.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reported-by: Jad Naous <jnaous@gmail.com>
|
|
skb_cow() has been present since 2.6.12 or earlier, but skb_cow_head() was
added only in 2.6.23, so we were checking for the wrong identifier here.
|
|
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.
|
|
An upcoming backport adds dev_get_stats() to a pre-2.6.29 Linux kernel, so we
have to check for the presence of an dev_get_stats() definition instead of for
the particular kernel version.
|
|
An upcoming backport adds skb_dst() to a pre-2.6.31 Linux kernel, so we
have to check for the presence of an skb_dst() definition instead of for
the particular kernel version.
|
|
These were getting to be hard to read, so I put them into alphabetical
groups by file and then sorted by identifier within a file.
|
|
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.
|
|
Some distributions backport this function, so use a configure
test instead of a version check.
CC: Alexey I. Froloff <raorn@altlinux.org>
|
|
The new GRE code requires the kmemdup function, but it's not available
on 2.6.18 kernels. It has been backported to Xen, so only define it for
non-Xen kernels older than 2.6.19.
|
|
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".
|
|
If the argument to --with-l26 is given as a relative pathname, then if
configuration succeeds, the build will fail, because the current directory
during the kernel build is different from that at configuration time.
Avoid the problem by converting the argument to an absolute path if
necessary.
|
|
The 2.6.33 kernel moves generated header files to include/generated, so
we need to look for autoconf.h there.
Reported-by: Brandon Heller <brandonh@stanford.edu>
|
|
Conflicts:
COPYING
datapath/datapath.h
lib/automake.mk
lib/dpif-provider.h
lib/dpif.c
lib/hmap.h
lib/netdev-provider.h
lib/netdev.c
lib/stream-ssl.h
ofproto/executer.c
ofproto/ofproto.c
ofproto/ofproto.h
tests/automake.mk
utilities/ovs-ofctl.c
utilities/ovs-vsctl.in
vswitchd/ovs-vswitchd.conf.5.in
xenserver/etc_init.d_vswitch
xenserver/etc_xensource_scripts_vif
xenserver/opt_xensource_libexec_interface-reconfigure
|
|
The check for strtok_r() prints a line of text on stdout as part of its
run. This is noticeable when running "configure", especially with -q.
This commit fixes it.
(The apparent alternative of not printing anything at all seems like a bad
idea because this might encourage the compiler to completely optimize
everything out of main().)
|
|
Debian's kernel-headers packages starting from 2.6.32 (or thereabouts) put
links to the kernel build and source directories at the same level, named
"build" and "source" respectively. Add support for this structure.
|
|
|
|
The C source and header files added in this commit is covered under the
InMon sFlow license at http://www.inmon.com/technology/sflowlicense.txt
The library requires -Wno-unused to compile without warnings, so this
commit adds that for building the sFlow code only. Automake can only
change compiler flags on a per-library or per-program basis, so sFlow
is built as a separate library.
The library will be used in upcoming commits.
|
|
This implements the kernel portion of GRE on Linux. It consists
of a backported module that provides the GRE capabilities of 2.6.32
plus bug fixes to kernels 2.6.18+.
|
|
C compiler warning options added by the "configure" script have until
now been put into CFLAGS. However that option is supposed to be reserved
for the user under Automake rules, so move them to AM_CFLAGS.
Besides increased adherence to Automake rules, this is useful because
AM_CFLAGS can be overridden on a per-target (e.g. program or library)
basis, whereas CFLAGS cannot. In turn, building the sFlow library (which
will be added in an upcoming commit) requires overriding the compiler
flags to avoid some warning messages. (By modifying the warning flags, we
avoid the need to modify the sFlow library in any way.)
|
|
Both ; and : are valid shell commands here, but one branch of the "if"
uses one and the other branch uses the other. Use the same one, for
consistency's sake.
|
|
Commit 5ef800a69 "datapath: Copy Xen's checksumming fields when doing
skb_copy" should copy proto_data_valid between sk_buffs when that field
is present. However the check for CONFIG_XEN plus kernel version 2.6.18
isn't sufficient, because SLES 11 kernels are version 2.6.27 but do have
this field.
This commit adds a configure-time check for the presence of the member
instead of attempting to guess based on the kernel version.
Thanks to Ian Campbell for reporting this problem.
CC: <Ian.Campbell@citrix.com>
|
|
Recent Debian kernel-header packages divide kernel headers into two
directories: the "common" headers that are not architecture-specific,
which go in a directory named like
/usr/src/kernel-headers-2.6.31-1-common,
and architecture-specific headers in a directory named, e.g.
/usr/src/kernel-headers-2.6.31-1-686.
OVS needs to look at the ones in the "common" directory as part of its
configuration process, but the build directory provided on --with-l26 is
the architecture-specific directory. We also need the
architecture-specific directory, since it is the one that we use as part
of the "make", so we can't simply make the user specify the common
directory on --with-l26. Furthermore, there is no easy-to-see link
between the two directories, except as part of the text in a Makefile,
which is not the easiest language to parse.
This commit attempts to kluge around the problem by using the Debian
directory naming. If the build directory does not contain the headers,
then we replace the last component of its name by "-common" and check
for the headers there. This is not ideal, but it does solve the actual
problem at hand.
Tested with Debian's linux-headers-2.6.31-1-686 and with a few older
sets of headers that do not use this scheme.
|
