summaryrefslogtreecommitdiff
path: root/lib/unaligned.h
Commit message (Collapse)AuthorAgeFilesLines
* Move lib/type-props.h to include/openvswitch directoryBen Warren2016-04-141-1/+1
| | | | | Signed-off-by: Ben Warren <ben@skyportsystems.com> Signed-off-by: Ben Pfaff <blp@ovn.org>
* unaligned: Make get_unaligned_be64() compatible on GCC and non-GCC.Ben Pfaff2014-10-091-23/+35
| | | | | | | | | | | | | | | | | | | | | | | | | Until now, with GCC, get_unaligned_be64() had an interface that accepted a "ovs_be64 *", and with other compilers its accepted any pointer-to-64-bit type, but not void *. This commit fixes the problem, making the interface the same in both cases. This fixes a build error on MSVC: lib/nx-match.c(320) : error C2100: illegal indirection lib/nx-match.c(320) : error C2034: 'build_assert_failed' : type of bit field too small for number of bits lib/nx-match.c(320) : error C2296: '%' : illegal, left operand has type 'void *' lib/nx-match.c(320) : error C2198: 'ntohll' : too few arguments for call It might appear that this patch changes get_unaligned_u64() but in fact it onloy moves it earlier in the file (since it is now called from the non-GCC fork of the #if). Reported-by: Alin Serdean <aserdean@cloudbasesolutions.com> Tested-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Acked-by: Alin Gabriel Serdean <aserdean@cloudbasesolutions.com> Signed-off-by: Ben Pfaff <blp@nicira.com>
* packets: Do not assume that IPv4, TCP, or ARP headers are 32-bit aligned.Ben Pfaff2013-08-271-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Global replace of Nicira Networks.Raju Subramanian2012-05-021-1/+1
| | | | | | | | 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>
* treewide: Convert tabs to spaces in C source files written in OVS style.Ben Pfaff2012-03-231-7/+7
| | | | | | | | | | | 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>
* dpif-linux: Fix build with certain 64-bit kernel/userspace combinations.Ben Pfaff2011-10-141-4/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make the source tree sparse clean.Ben Pfaff2011-05-161-0/+7
| | | | | | | | | | 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"
* Add types and accessors for working with half-aligned 64-bit values.Ben Pfaff2011-02-051-1/+40
| | | | | | | | 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.
* unaligned: Add unaligned accessors for ovs_be<N> data.Ben Pfaff2010-11-291-23/+45
| | | | | | 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.
* xtoxll: Rename "byte-order" since it now include more than xtoxll.Ben Pfaff2010-10-291-1/+1
| | | | Suggested-by: Justin Pettit <jpettit@nicira.com>
* Add header for access to potentially unaligned data.Ben Pfaff2010-05-071-0/+122
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.
View Lorry Controller Status