mir/ovs
2
0
Fork 0
mirror of https://github.com/openvswitch/ovs synced 2025-08-23 18:37:36 +00:00
Code Issues Releases Wiki Activity
ovs/lib/unaligned.h

224 lines
6.9 KiB
C
Raw Normal View History

Add header for access to potentially unaligned data. I had been under the impression that "memcpy" was a valid way to copy unaligned data into an aligned location for access. But testing on SPARC has shown that GCC doesn't always honor that intention. It seems that, if GCC can see that there is a pointer of a type that requires alignment to a given object, then it will access it directly regardless of whether memcpy() is used to copy it. This commit adds a new header with functions to access unaligned data. I managed to come up with two techniques, one GCC-specific, one generic, that do avoid the misaligned access in my test case. The GCC-specific technique is the same one used by the Linux kernel (although no code has been literally copied). The other one seemed obvious but possibly slow depending on the compiler's ability to optimize. The following commit adds a user.
2010-05-07 14:31:04 -07:00
/*
Add types and accessors for working with half-aligned 64-bit values. 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.
2011-02-05 13:14:47 -08:00
* Copyright (c) 2010, 2011 Nicira Networks.
Add header for access to potentially unaligned data. I had been under the impression that "memcpy" was a valid way to copy unaligned data into an aligned location for access. But testing on SPARC has shown that GCC doesn't always honor that intention. It seems that, if GCC can see that there is a pointer of a type that requires alignment to a given object, then it will access it directly regardless of whether memcpy() is used to copy it. This commit adds a new header with functions to access unaligned data. I managed to come up with two techniques, one GCC-specific, one generic, that do avoid the misaligned access in my test case. The GCC-specific technique is the same one used by the Linux kernel (although no code has been literally copied). The other one seemed obvious but possibly slow depending on the compiler's ability to optimize. The following commit adds a user.
2010-05-07 14:31:04 -07:00
*
* 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 UNALIGNED_H
#define UNALIGNED_H 1
#include <stdint.h>
xtoxll: Rename "byte-order" since it now include more than xtoxll. Suggested-by: Justin Pettit <jpettit@nicira.com>
2010-10-28 17:13:18 -07:00
#include "byte-order.h"
unaligned: Add unaligned accessors for ovs_be<N> data. These accessors are semantically identical to the ones for uint<N>_t data, but the names are more informative to readers, and the types provide annotations for sparse.
2010-11-15 15:53:00 -08:00
#include "openvswitch/types.h"
dpif-linux: Fix build with certain 64-bit kernel/userspace combinations. Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of these is a reasonable choice for uint64_t (the userspace type) and for __u64 (the kernel type). Unfortunately, kernel and userspace don't necessarily agree on the choice, and in fact the choice varies across kernel versions and architectures. Now that OVS is actually using kernel types in its kernel header, this can make a difference: when __u64 and uint64_t differ, passing a pointer to __u64 to OVS function get_unaligned_u64() yields a compiler warning or error. This commit fixes up the problems of this type found in OVS, by making get_unaligned_u64() accept all 64-bit unsigned integer types, not just whichever one happens to be uint64_t. I didn't do the same thing for put_unaligned_u64() because it is less likely to be a problem in practice: usually, when userspace writes to kernel data structures it does so with copies that it knows to be aligned, so that it's not necessary to use put_unaligned_u64(). This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is only one reasonable choice of type for each. It won't occur for ovs_be<N> because OVS always defines those as aliases for the kernel's __be<N> types when those are available. This compiled cleanly for me in Scientific Linux 6.0 x86-64. Reported-by: Pravin Shelar <pshelar@nicira.com>
2011-10-14 09:39:48 -07:00
#include "type-props.h"
#include "util.h"
Add header for access to potentially unaligned data. I had been under the impression that "memcpy" was a valid way to copy unaligned data into an aligned location for access. But testing on SPARC has shown that GCC doesn't always honor that intention. It seems that, if GCC can see that there is a pointer of a type that requires alignment to a given object, then it will access it directly regardless of whether memcpy() is used to copy it. This commit adds a new header with functions to access unaligned data. I managed to come up with two techniques, one GCC-specific, one generic, that do avoid the misaligned access in my test case. The GCC-specific technique is the same one used by the Linux kernel (although no code has been literally copied). The other one seemed obvious but possibly slow depending on the compiler's ability to optimize. The following commit adds a user.
2010-05-07 14:31:04 -07:00
/* Public API. */
static inline uint16_t get_unaligned_u16(const uint16_t *);
static inline uint32_t get_unaligned_u32(const uint32_t *);
static inline void put_unaligned_u16(uint16_t *, uint16_t);
static inline void put_unaligned_u32(uint32_t *, uint32_t);
static inline void put_unaligned_u64(uint64_t *, uint64_t);
unaligned: Add unaligned accessors for ovs_be<N> data. These accessors are semantically identical to the ones for uint<N>_t data, but the names are more informative to readers, and the types provide annotations for sparse.
2010-11-15 15:53:00 -08:00
static inline ovs_be16 get_unaligned_be16(const ovs_be16 *);
static inline ovs_be32 get_unaligned_be32(const ovs_be32 *);
static inline ovs_be64 get_unaligned_be64(const ovs_be64 *);
static inline void put_unaligned_be16(ovs_be16 *, ovs_be16);
static inline void put_unaligned_be32(ovs_be32 *, ovs_be32);
static inline void put_unaligned_be64(ovs_be64 *, ovs_be64);
Add header for access to potentially unaligned data. I had been under the impression that "memcpy" was a valid way to copy unaligned data into an aligned location for access. But testing on SPARC has shown that GCC doesn't always honor that intention. It seems that, if GCC can see that there is a pointer of a type that requires alignment to a given object, then it will access it directly regardless of whether memcpy() is used to copy it. This commit adds a new header with functions to access unaligned data. I managed to come up with two techniques, one GCC-specific, one generic, that do avoid the misaligned access in my test case. The GCC-specific technique is the same one used by the Linux kernel (although no code has been literally copied). The other one seemed obvious but possibly slow depending on the compiler's ability to optimize. The following commit adds a user.
2010-05-07 14:31:04 -07:00
#ifdef __GNUC__
/* GCC implementations. */
unaligned: Add unaligned accessors for ovs_be<N> data. These accessors are semantically identical to the ones for uint<N>_t data, but the names are more informative to readers, and the types provide annotations for sparse.
2010-11-15 15:53:00 -08:00
#define GCC_UNALIGNED_ACCESSORS(TYPE, ABBREV) \
struct unaligned_##ABBREV { \
TYPE x __attribute__((__packed__)); \
}; \
static inline struct unaligned_##ABBREV * \
unaligned_##ABBREV(const TYPE *p) \
{ \
return (struct unaligned_##ABBREV *) p; \
} \
\
static inline TYPE \
get_unaligned_##ABBREV(const TYPE *p) \
{ \
return unaligned_##ABBREV(p)->x; \
} \
\
static inline void \
put_unaligned_##ABBREV(TYPE *p, TYPE x) \
{ \
unaligned_##ABBREV(p)->x = x; \
Add header for access to potentially unaligned data. I had been under the impression that "memcpy" was a valid way to copy unaligned data into an aligned location for access. But testing on SPARC has shown that GCC doesn't always honor that intention. It seems that, if GCC can see that there is a pointer of a type that requires alignment to a given object, then it will access it directly regardless of whether memcpy() is used to copy it. This commit adds a new header with functions to access unaligned data. I managed to come up with two techniques, one GCC-specific, one generic, that do avoid the misaligned access in my test case. The GCC-specific technique is the same one used by the Linux kernel (although no code has been literally copied). The other one seemed obvious but possibly slow depending on the compiler's ability to optimize. The following commit adds a user.
2010-05-07 14:31:04 -07:00
}
unaligned: Add unaligned accessors for ovs_be<N> data. These accessors are semantically identical to the ones for uint<N>_t data, but the names are more informative to readers, and the types provide annotations for sparse.
2010-11-15 15:53:00 -08:00
GCC_UNALIGNED_ACCESSORS(uint16_t, u16);
GCC_UNALIGNED_ACCESSORS(uint32_t, u32);
dpif-linux: Fix build with certain 64-bit kernel/userspace combinations. Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of these is a reasonable choice for uint64_t (the userspace type) and for __u64 (the kernel type). Unfortunately, kernel and userspace don't necessarily agree on the choice, and in fact the choice varies across kernel versions and architectures. Now that OVS is actually using kernel types in its kernel header, this can make a difference: when __u64 and uint64_t differ, passing a pointer to __u64 to OVS function get_unaligned_u64() yields a compiler warning or error. This commit fixes up the problems of this type found in OVS, by making get_unaligned_u64() accept all 64-bit unsigned integer types, not just whichever one happens to be uint64_t. I didn't do the same thing for put_unaligned_u64() because it is less likely to be a problem in practice: usually, when userspace writes to kernel data structures it does so with copies that it knows to be aligned, so that it's not necessary to use put_unaligned_u64(). This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is only one reasonable choice of type for each. It won't occur for ovs_be<N> because OVS always defines those as aliases for the kernel's __be<N> types when those are available. This compiled cleanly for me in Scientific Linux 6.0 x86-64. Reported-by: Pravin Shelar <pshelar@nicira.com>
2011-10-14 09:39:48 -07:00
GCC_UNALIGNED_ACCESSORS(uint64_t, u64__); /* Special case: see below. */
unaligned: Add unaligned accessors for ovs_be<N> data. These accessors are semantically identical to the ones for uint<N>_t data, but the names are more informative to readers, and the types provide annotations for sparse.
2010-11-15 15:53:00 -08:00
GCC_UNALIGNED_ACCESSORS(ovs_be16, be16);
GCC_UNALIGNED_ACCESSORS(ovs_be32, be32);
GCC_UNALIGNED_ACCESSORS(ovs_be64, be64);
Add header for access to potentially unaligned data. I had been under the impression that "memcpy" was a valid way to copy unaligned data into an aligned location for access. But testing on SPARC has shown that GCC doesn't always honor that intention. It seems that, if GCC can see that there is a pointer of a type that requires alignment to a given object, then it will access it directly regardless of whether memcpy() is used to copy it. This commit adds a new header with functions to access unaligned data. I managed to come up with two techniques, one GCC-specific, one generic, that do avoid the misaligned access in my test case. The GCC-specific technique is the same one used by the Linux kernel (although no code has been literally copied). The other one seemed obvious but possibly slow depending on the compiler's ability to optimize. The following commit adds a user.
2010-05-07 14:31:04 -07:00
#else
/* Generic implementations. */
static inline uint16_t get_unaligned_u16(const uint16_t *p_)
{
const uint8_t *p = (const uint8_t *) p_;
return ntohs((p[0] << 8) | p[1]);
}
static inline void put_unaligned_u16(uint16_t *p_, uint16_t x_)
{
uint8_t *p = (uint8_t *) p_;
uint16_t x = ntohs(x_);
p[0] = x >> 8;
p[1] = x;
}
static inline uint32_t get_unaligned_u32(const uint32_t *p_)
{
const uint8_t *p = (const uint8_t *) p_;
return ntohl((p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]);
}
static inline void put_unaligned_u32(uint32_t *p_, uint32_t x_)
{
uint8_t *p = (uint8_t *) p_;
uint32_t x = ntohl(x_);
p[0] = x >> 24;
p[1] = x >> 16;
p[2] = x >> 8;
p[3] = x;
}
dpif-linux: Fix build with certain 64-bit kernel/userspace combinations. Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of these is a reasonable choice for uint64_t (the userspace type) and for __u64 (the kernel type). Unfortunately, kernel and userspace don't necessarily agree on the choice, and in fact the choice varies across kernel versions and architectures. Now that OVS is actually using kernel types in its kernel header, this can make a difference: when __u64 and uint64_t differ, passing a pointer to __u64 to OVS function get_unaligned_u64() yields a compiler warning or error. This commit fixes up the problems of this type found in OVS, by making get_unaligned_u64() accept all 64-bit unsigned integer types, not just whichever one happens to be uint64_t. I didn't do the same thing for put_unaligned_u64() because it is less likely to be a problem in practice: usually, when userspace writes to kernel data structures it does so with copies that it knows to be aligned, so that it's not necessary to use put_unaligned_u64(). This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is only one reasonable choice of type for each. It won't occur for ovs_be<N> because OVS always defines those as aliases for the kernel's __be<N> types when those are available. This compiled cleanly for me in Scientific Linux 6.0 x86-64. Reported-by: Pravin Shelar <pshelar@nicira.com>
2011-10-14 09:39:48 -07:00
static inline uint64_t get_unaligned_u64__(const uint64_t *p_)
Add header for access to potentially unaligned data. I had been under the impression that "memcpy" was a valid way to copy unaligned data into an aligned location for access. But testing on SPARC has shown that GCC doesn't always honor that intention. It seems that, if GCC can see that there is a pointer of a type that requires alignment to a given object, then it will access it directly regardless of whether memcpy() is used to copy it. This commit adds a new header with functions to access unaligned data. I managed to come up with two techniques, one GCC-specific, one generic, that do avoid the misaligned access in my test case. The GCC-specific technique is the same one used by the Linux kernel (although no code has been literally copied). The other one seemed obvious but possibly slow depending on the compiler's ability to optimize. The following commit adds a user.
2010-05-07 14:31:04 -07:00
{
const uint8_t *p = (const uint8_t *) p_;
return ntohll(((uint64_t) p[0] << 56)
| ((uint64_t) p[1] << 48)
| ((uint64_t) p[2] << 40)
| ((uint64_t) p[3] << 32)
| (p[4] << 24)
| (p[5] << 16)
| (p[6] << 8)
| p[7]);
}
dpif-linux: Fix build with certain 64-bit kernel/userspace combinations. Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of these is a reasonable choice for uint64_t (the userspace type) and for __u64 (the kernel type). Unfortunately, kernel and userspace don't necessarily agree on the choice, and in fact the choice varies across kernel versions and architectures. Now that OVS is actually using kernel types in its kernel header, this can make a difference: when __u64 and uint64_t differ, passing a pointer to __u64 to OVS function get_unaligned_u64() yields a compiler warning or error. This commit fixes up the problems of this type found in OVS, by making get_unaligned_u64() accept all 64-bit unsigned integer types, not just whichever one happens to be uint64_t. I didn't do the same thing for put_unaligned_u64() because it is less likely to be a problem in practice: usually, when userspace writes to kernel data structures it does so with copies that it knows to be aligned, so that it's not necessary to use put_unaligned_u64(). This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is only one reasonable choice of type for each. It won't occur for ovs_be<N> because OVS always defines those as aliases for the kernel's __be<N> types when those are available. This compiled cleanly for me in Scientific Linux 6.0 x86-64. Reported-by: Pravin Shelar <pshelar@nicira.com>
2011-10-14 09:39:48 -07:00
static inline void put_unaligned_u64__(uint64_t *p_, uint64_t x_)
Add header for access to potentially unaligned data. I had been under the impression that "memcpy" was a valid way to copy unaligned data into an aligned location for access. But testing on SPARC has shown that GCC doesn't always honor that intention. It seems that, if GCC can see that there is a pointer of a type that requires alignment to a given object, then it will access it directly regardless of whether memcpy() is used to copy it. This commit adds a new header with functions to access unaligned data. I managed to come up with two techniques, one GCC-specific, one generic, that do avoid the misaligned access in my test case. The GCC-specific technique is the same one used by the Linux kernel (although no code has been literally copied). The other one seemed obvious but possibly slow depending on the compiler's ability to optimize. The following commit adds a user.
2010-05-07 14:31:04 -07:00
{
uint8_t *p = (uint8_t *) p_;
uint64_t x = ntohll(x_);
p[0] = x >> 56;
p[1] = x >> 48;
p[2] = x >> 40;
p[3] = x >> 32;
p[4] = x >> 24;
p[5] = x >> 16;
p[6] = x >> 8;
p[7] = x;
}
unaligned: Add unaligned accessors for ovs_be<N> data. These accessors are semantically identical to the ones for uint<N>_t data, but the names are more informative to readers, and the types provide annotations for sparse.
2010-11-15 15:53:00 -08:00
/* Only sparse cares about the difference between uint<N>_t and ovs_be<N>, and
* that takes the GCC branch, so there's no point in working too hard on these
* accessors. */
#define get_unaligned_be16 get_unaligned_u16
#define get_unaligned_be32 get_unaligned_u32
#define get_unaligned_be64 get_unaligned_u64
#define put_unaligned_be16 put_unaligned_u16
#define put_unaligned_be32 put_unaligned_u32
#define put_unaligned_be64 put_unaligned_u64
Add header for access to potentially unaligned data. I had been under the impression that "memcpy" was a valid way to copy unaligned data into an aligned location for access. But testing on SPARC has shown that GCC doesn't always honor that intention. It seems that, if GCC can see that there is a pointer of a type that requires alignment to a given object, then it will access it directly regardless of whether memcpy() is used to copy it. This commit adds a new header with functions to access unaligned data. I managed to come up with two techniques, one GCC-specific, one generic, that do avoid the misaligned access in my test case. The GCC-specific technique is the same one used by the Linux kernel (although no code has been literally copied). The other one seemed obvious but possibly slow depending on the compiler's ability to optimize. The following commit adds a user.
2010-05-07 14:31:04 -07:00
#endif
dpif-linux: Fix build with certain 64-bit kernel/userspace combinations. Unix 64-bit ABIs have two 64-bit types: "long" and "long long". Either of these is a reasonable choice for uint64_t (the userspace type) and for __u64 (the kernel type). Unfortunately, kernel and userspace don't necessarily agree on the choice, and in fact the choice varies across kernel versions and architectures. Now that OVS is actually using kernel types in its kernel header, this can make a difference: when __u64 and uint64_t differ, passing a pointer to __u64 to OVS function get_unaligned_u64() yields a compiler warning or error. This commit fixes up the problems of this type found in OVS, by making get_unaligned_u64() accept all 64-bit unsigned integer types, not just whichever one happens to be uint64_t. I didn't do the same thing for put_unaligned_u64() because it is less likely to be a problem in practice: usually, when userspace writes to kernel data structures it does so with copies that it knows to be aligned, so that it's not necessary to use put_unaligned_u64(). This problem won't occur for uint8_t, uint16_t, or uint32_t, since there is only one reasonable choice of type for each. It won't occur for ovs_be<N> because OVS always defines those as aliases for the kernel's __be<N> types when those are available. This compiled cleanly for me in Scientific Linux 6.0 x86-64. Reported-by: Pravin Shelar <pshelar@nicira.com>
2011-10-14 09:39:48 -07:00
/* uint64_t get_unaligned_u64(uint64_t *p);
*
* Returns the value of the possibly misaligned uint64_t at 'p'. 'p' may
* actually be any type that points to a 64-bit integer. That is, on Unix-like
* 32-bit ABIs, it may point to an "unsigned long long int", and on Unix-like
* 64-bit ABIs, it may point to an "unsigned long int" or an "unsigned long
* long int".
*
* This is special-cased because on some Linux targets, the kernel __u64 is
* unsigned long long int and the userspace uint64_t is unsigned long int, so
* that any single function prototype would fail to accept one or the other.
*
* Below, "sizeof (*(P) % 1)" verifies that *P has an integer type, since
* operands to % must be integers.
*/
#define get_unaligned_u64(P) \
(BUILD_ASSERT(sizeof *(P) == 8), \
BUILD_ASSERT_GCCONLY(!TYPE_IS_SIGNED(typeof(*(P)))), \
(void) sizeof (*(P) % 1), \
get_unaligned_u64__((const uint64_t *) (P)))
/* Stores 'x' at possibly misaligned address 'p'.
*
* put_unaligned_u64() could be overloaded in the same way as
* get_unaligned_u64(), but so far it has not proven necessary.
*/
static inline void
put_unaligned_u64(uint64_t *p, uint64_t x)
{
put_unaligned_u64__(p, x);
}
Add types and accessors for working with half-aligned 64-bit values. 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.
2011-02-05 13:14:47 -08:00
/* Returns the value in 'x'. */
static inline uint64_t
get_32aligned_u64(const ovs_32aligned_u64 *x)
{
return ((uint64_t) x->hi << 32) | x->lo;
}
/* Stores 'value' in 'x'. */
static inline void
put_32aligned_u64(ovs_32aligned_u64 *x, uint64_t value)
{
x->hi = value >> 32;
x->lo = value;
}
Make the source tree sparse clean. 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"
2011-05-06 12:59:51 -07:00
#ifndef __CHECKER__
Add types and accessors for working with half-aligned 64-bit values. 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.
2011-02-05 13:14:47 -08:00
/* Returns the value of 'x'. */
static inline ovs_be64
get_32aligned_be64(const ovs_32aligned_be64 *x)
{
#ifdef WORDS_BIGENDIAN
return ((ovs_be64) x->hi << 32) | x->lo;
#else
return ((ovs_be64) x->lo << 32) | x->hi;
#endif
}
/* Stores network byte order 'value' into 'x'. */
static inline void
put_32aligned_be64(ovs_32aligned_be64 *x, ovs_be64 value)
{
#if WORDS_BIGENDIAN
x->hi = value >> 32;
x->lo = value;
#else
x->hi = value;
x->lo = value >> 32;
#endif
}
Make the source tree sparse clean. 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"
2011-05-06 12:59:51 -07:00
#else /* __CHECKER__ */
/* Making sparse happy with these functions also makes them unreadable, so
* don't bother to show it their implementations. */
ovs_be64 get_32aligned_be64(const ovs_32aligned_be64 *);
void put_32aligned_be64(ovs_32aligned_be64 *, ovs_be64);
#endif
Add header for access to potentially unaligned data. I had been under the impression that "memcpy" was a valid way to copy unaligned data into an aligned location for access. But testing on SPARC has shown that GCC doesn't always honor that intention. It seems that, if GCC can see that there is a pointer of a type that requires alignment to a given object, then it will access it directly regardless of whether memcpy() is used to copy it. This commit adds a new header with functions to access unaligned data. I managed to come up with two techniques, one GCC-specific, one generic, that do avoid the misaligned access in my test case. The GCC-specific technique is the same one used by the Linux kernel (although no code has been literally copied). The other one seemed obvious but possibly slow depending on the compiler's ability to optimize. The following commit adds a user.
2010-05-07 14:31:04 -07:00
#endif /* unaligned.h */
Reference in New Issue Copy Permalink