The stats(byte_count) is got via function call
ofputil_decode_flow_stats_reply() and for OpenFlow15 it will also call
oxs_pull_entry__(). Currently we found on Windows the byte_count
counter is incorrect. It will get the byte_count on OpenFlow15
handling via ntohll(get_unaligned_be64(payload))
Quote the comments below from Ilya Maximets (thanks for the given
soluton and explanation):
static inline uint64_t get_unaligned_u64__(const uint64_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]);
And indeed the expression above has an issue with data types.
The problem is the (p[4] << 24) part. The p[4] itself has a type
'uint8_t' which is unsigned 8bit value. It is not enough to hold
the result of a left shift, so compiler automatically promotes it
to the 'int' by default. But it is *signed* 32bit value.
In your original report p[4] was equal to 0x81. After the left
shift it became 0x81000000. Looks correct, but the type is 'int'.
The next operation that we do is '|' with the previous shifted
bytes that were explicitly converted to uint64_t before the left
shift. So we have uint64_t | int. In this case compiler needs
to extend the 'int' to 'unit64_t' before performing the operation.
And since the 'int' is signed and the sign bit happens to be set
in the 0x81000000, the sign extension is performed in order to
preserve the value. The result is 0xffffffff81000000. And that
is breaking everything else.
From the new test below, it is incorrect for the n_bytes counter via
OpenFlow15 on CMD: ovs-ofctl dump-flows.
With the patch, get_unaligned_u64__() will return correct value to
caller on Windows.
In the output (Got via original CMD without fix) below n_bytes
2177130813 will be incorrectly changed to 18446744071591715133 when
processing OpenFlow15 which is equal to 0xFFFFFFFF81C4613D and here
the p[4] on Windows is 0x81.
With the fix, new compiled ovs-ofctl1025.exe could dump the correct
n_bytes counter Via OpenFlow15.
ovs-ofctl.exe -O OpenFlow15 dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=18446744071591715133,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=18446744071591715133,
ovs-ofctl.exe -O OpenFlow10 dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
ovs-ofctl.exe dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
With the fix, new compiled ovs-ofctl1025.exe could dump the correct
n_bytes counter Via OpenFlow15.
ovs-ofctl1025.exe -O OpenFlow15 dump-flows nsx-managed | findstr 1516011
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
cookie=<>, duration=<>s, table=4, n_packets=1516011, n_bytes=2177130813,
Fixes: afa3a93165f1 ("Add header for access to potentially unaligned data.")
Signed-off-by: Wilson Peng <pweisong@vmware.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
This change fixes compilation issues related to designated
initializers, which are not supported by C++ compiler.
Signed-off-by: Shireesh Kumar Singh <shireeshkum@vmware.com>
Signed-off-by: Sairam Venugopal <vsairam@vmware.com>
Co-authored-by: Sairam Venugopal <vsairam@vmware.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
These are analogous to the existing helpers for 32-bit aligned 64-bit
integers, and will have users in upcoming commits.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Lance Richardson <lrichard@redhat.com>
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>
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>
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>
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>
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"
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.
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.
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.
