2
0
mirror of https://github.com/openvswitch/ovs synced 2025-08-22 18:07:40 +00:00

120 lines
3.7 KiB
C
Raw Normal View History

/*
* Copyright (c) 2010, 2011, 2013, 2014 Nicira, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#ifndef OPENVSWITCH_TYPES_H
#define OPENVSWITCH_TYPES_H 1
#include <sys/types.h>
#include <stdint.h>
#ifdef __CHECKER__
#define OVS_BITWISE __attribute__((bitwise))
#define OVS_FORCE __attribute__((force))
#else
#define OVS_BITWISE
#define OVS_FORCE
#endif
/* The ovs_be<N> types indicate that an object is in big-endian, not
* native-endian, byte order. They are otherwise equivalent to uint<N>_t. */
typedef uint16_t OVS_BITWISE ovs_be16;
typedef uint32_t OVS_BITWISE ovs_be32;
typedef uint64_t OVS_BITWISE ovs_be64;
#define OVS_BE16_MAX ((OVS_FORCE ovs_be16) 0xffff)
#define OVS_BE32_MAX ((OVS_FORCE ovs_be32) 0xffffffff)
#define OVS_BE64_MAX ((OVS_FORCE ovs_be64) 0xffffffffffffffffULL)
packets: Do not assume that IPv4, TCP, or ARP headers are 32-bit aligned. 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>
2013-08-15 10:47:39 -07:00
/* These types help with a few funny situations:
*
* - The Ethernet header is 14 bytes long, which misaligns everything after
* that. One can put 2 "shim" bytes before the Ethernet header, but this
* helps only if there is exactly one Ethernet header. If there are two,
* as with GRE and VXLAN (and if the inner header doesn't use this
* trick--GRE and VXLAN don't) then you have the choice of aligning the
* inner data or the outer data. So it seems better to treat 32-bit fields
* in protocol headers as aligned only on 16-bit boundaries.
*
* - ARP headers contain misaligned 32-bit fields.
*
* - Netlink and OpenFlow contain 64-bit values that are only guaranteed to
* be aligned on 32-bit boundaries.
*
* lib/unaligned.h has helper functions for accessing these. */
packets: Do not assume that IPv4, TCP, or ARP headers are 32-bit aligned. 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>
2013-08-15 10:47:39 -07:00
/* A 32-bit value, in host byte order, that is only aligned on a 16-bit
* boundary. */
typedef struct {
#ifdef WORDS_BIGENDIAN
uint16_t hi, lo;
#else
uint16_t lo, hi;
#endif
} ovs_16aligned_u32;
/* A 32-bit value, in network byte order, that is only aligned on a 16-bit
* boundary. */
typedef struct {
ovs_be16 hi, lo;
} ovs_16aligned_be32;
/* A 64-bit value, in host byte order, that is only aligned on a 32-bit
* boundary. */
typedef struct {
#ifdef WORDS_BIGENDIAN
uint32_t hi, lo;
#else
uint32_t lo, hi;
#endif
} ovs_32aligned_u64;
typedef union {
uint32_t u32[4];
struct {
uint64_t lo, hi;
} u64;
} ovs_u128;
/* A 64-bit value, in network byte order, that is only aligned on a 32-bit
* boundary. */
typedef struct {
ovs_be32 hi, lo;
} ovs_32aligned_be64;
/* ofp_port_t represents the port number of a OpenFlow switch.
* odp_port_t represents the port number on the datapath.
* ofp11_port_t represents the OpenFlow-1.1 port number. */
typedef uint16_t OVS_BITWISE ofp_port_t;
typedef uint32_t OVS_BITWISE odp_port_t;
typedef uint32_t OVS_BITWISE ofp11_port_t;
/* Macro functions that cast int types to ofp/odp/ofp11 types. */
#define OFP_PORT_C(X) ((OVS_FORCE ofp_port_t) (X))
#define ODP_PORT_C(X) ((OVS_FORCE odp_port_t) (X))
#define OFP11_PORT_C(X) ((OVS_FORCE ofp11_port_t) (X))
/* Using this stuct instead of a bare array makes an ethernet address field
* assignable. The size of the array is also part of the type, so it is easier
* to deal with. */
struct eth_addr {
union {
uint8_t ea[6];
ovs_be16 be16[3];
};
};
#endif /* openvswitch/types.h */