This fixes several tests that failed on big-endian systems because "union
flow_in_port" overlays an ofp_port_t and odp_port_t and in some cases it
is not easy to determine which one is in use.
This commit also fixes up a few places where this broke other code.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Aaron Conole <aconole@redhat.com>
Acked-by: Gerhard Stenzel <gstenzel@linux.vnet.ibm.com>
warning: ‘OVS_BE128_MAX’ defined but not used [-Wunused-const-variable]
Found using CentOS 6.6 with gcc 6.0.0.
Signed-off-by: William Tu <u9012063@gmail.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
The previous definitions of these variables using designated
initializers caused a variety of issues when attempting to compile with
MSVC, particularly if including these headers from C++ code. By defining
them like this, we can appease MSVC and keep the definitions the same on
all platforms.
VMware-BZ: #1517163
Suggested-by: Yin Lin <linyi@vmware.com>
Signed-off-by: Joe Stringer <joe@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
These types will be used by the following patches to ensure a consistent
wire format for 128-bit connection tracking labels. Common functions for
comparison, endian translation, etc. are provided.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Define struct eth_addr and use it instead of a uint8_t array for all
ethernet addresses in OVS userspace. The struct is always the right
size, and it can be assigned without an explicit memcpy, which makes
code more readable.
"struct eth_addr" is a good type name for this as many utility
functions are already named accordingly.
struct eth_addr can be accessed as bytes as well as ovs_be16's, which
makes the struct 16-bit aligned. All use seems to be 16-bit aligned,
so some algorithms on the ethernet addresses can be made a bit more
efficient making use of this fact.
As the struct fits into a register (in 64-bit systems) we pass it by
value when possible.
This patch also changes the few uses of Linux specific ETH_ALEN to
OVS's own ETH_ADDR_LEN, and removes the OFP_ETH_ALEN, as it is no
longer needed.
This work stemmed from a desire to make all struct flow members
assignable for unrelated exploration purposes. However, I think this
might be a nice code readability improvement by itself.
Signed-off-by: Jarno Rajahalme <jrajahalme@nicira.com>
This function doesn't need to be exported in the public OVS headers, and
it had an inconsistent name compared to uuid_equals(). Rename and move.
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Until now, the OVS source tree has had a whole maze of header files that
make "#include <linux/openvswitch.h>" work OK regardless of platform, but
this confuses everyone new to the tree, at first glance, and is difficult
to understand at second glance too.
This commit renames include/linux/openvswitch.h to
datapath/linux/compat/include/linux/openvswitch.h without other change,
then modifies the userspace build to generate a header that makes sense in
portable Open vSwitch userspace from that header.
It then removes all the remaining include/linux/* files since they are now
unused.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Ethernet headers are 14 bytes long, so when the beginning of such a header
is 32-bit aligned, the following data is misaligned. The usual trick to
fix that is to start the Ethernet header on an odd-numbered 16-bit
boundary. That trick works OK for Open vSwitch, but there are two
problems:
- OVS doesn't use that trick everywhere. Maybe it should, but it's
difficult to make sure that it does consistently because the CPUs
most commonly used with OVS don't care about misalignment, so we
only find problems when porting.
- Some protocols (GRE, VXLAN) don't use that trick, so in such a case
one can properly align the inner or outer L3/L4/L7 but not both. (OVS
userspace doesn't directly deal with such protocols yet, so this is
just future-proofing.)
- OpenFlow uses the alignment trick in a few places but not all of them.
This commit starts the adoption of what I hope will be a more robust way
to avoid misalignment problems and the resulting bus errors on RISC
architectures. Instead of trying to ensure that 32-bit quantities are
always aligned, we always read them as if they were misaligned. To ensure
that they are read this way, we change their types from 32-bit types to
pairs of 16-bit types. (I don't know of any protocols that offset the
next header by an odd number of bytes, so a 16-bit alignment assumption
seems OK.)
The same would be necessary for 64-bit types in protocol headers, but we
don't yet have any protocol definitions with 64-bit types.
IPv6 protocol headers need the same treatment, but for those we rely on
structs provided by system headers, so I'll leave them for an upcoming
patch.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Until now, datapath ports and openflow ports were both represented by
unsigned integers of various sizes. With implicit conversions, etc., it is
easy to mix them up and use one where the other is expected. This commit
creates two typedefs, ofp_port_t and odp_port_t. Both of these two types
are marked by "__attribute__((bitwise))" so that sparse can be used to
detect any misuse.
Signed-off-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The Open vSwitch C style doesn't use hard tabs.
This commit doesn't touch files written in kernel style or that are
imported from other projects where we want to minimize changes from
upstream (the sflow files).
Reported-by: Mehak Mahajan <mmahajan@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
We want datapath-protocol.h to be acceptable as a Linux kernel header, so
it must use Linux kernel types and must not have references to Open vSwitch
symbols or header files. This commit primarily makes that change to
datapath-protocol.h.
At the same time, at least for now we also want datapath-protocol.h to be
usable on non-Linux platforms, so we need some kind of compatiblity. Thus,
this commit also introduces a <linux/types.h> header file that defines the
necessary Linux kernel types on non-Linux platforms.
In turn, this requires openvswitch/types.h to use the Linux types directly
for ovs_be<N>; otherwise, sparse complains because now __be<N> and
ovs_be<N> are incompatible from its perspective, so this commit makes that
change too.
I don't have a non-Linux kernel platform readily available, so I only
tested the non-Linux part of the linux/types.h substitute by forcing that
case to be triggered with #if 0. It worked, except for errors in actual
Linux kernel headers included explicitly from OVS source files, so I think
it's likely to work in practice.
Bug #7559.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Both OpenFlow and Netlink contain 64-bit fields that are only guaranteed
to be aligned on 32-bit boundaries. This commit introduces types for
representing these fields and functions for working with them. Followup
commits will make the OpenFlow and Netlink code use these types and
functions.
Originally, wildcards were just the OpenFlow OFPFW_* bits. Then, when
OpenFlow added CIDR masks for IP addresses, struct flow_wildcards was born
with additional members for those masks, derived from the wildcard bits.
Then, when OVS added support for tunnels, we added another bit
NXFW_TUN_ID that coexisted with the OFPFW_*. Later we added even more bits
that do not appear in the OpenFlow 1.0 match structure at all. This had
become really confusing, and the difficulties were especially visible in
the long list of invariants in comments on struct flow_wildcards.
This commit cleanly separates the OpenFlow 1.0 wildcard bits from the
bits used inside Open vSwitch, by defining a new set of bits that are
used only internally to Open vSwitch and converting to and from those
wildcard bits at the point where data comes off or goes onto the wire.
It also moves those functions into ofp-util.[ch] since they are only for
dealing with OpenFlow wire protocol now.
