[ovs-discuss] Failing ovs tests on big-endian system
blp at nicira.com
Thu Nov 27 16:33:51 UTC 2014
On Thu, Nov 27, 2014 at 03:41:56PM +0100, Mijo Safradin wrote:
> >>For instance, by looking at the testcase 79 "flow classifier -
> >>lookup segmentation" it shows that at lib/classifier.c the function
> >>miniflow_and_mask_matches_flow_wc() does process the bitwise OR in
> >>wrong order. By introducing the function le32toh(), the test does
> >>pass on a little and big endian system.
> >I don't understand why you need to do this. OVS internally does use
> >host byte order and network byte order, but it doesn't intentionally
> >maintain any data in little-endian order. Can you explain further?
> I haven't digged further. I can only share the fact that the byte order
> differs here on a x86 compared to a power/s390 system. Because, you say this
> shouldn't be the case, I can try to debug this further.
> >Does this only happen on master? Version 2.3.x passes all of the
> >tests on big-endian and little-endian systems:
> It fails on master and on older git versions as well. Even using Debian Sid,
> the same errors could be observed. Can you provide hardware details about
> the power/s390 machines the mentioned test has been executed on?
Basics about the machines are in the Debian machine database:
The mips machine: https://db.debian.org/machines.cgi?host=corelli
The powerpc machine: https://db.debian.org/machines.cgi?host=poulenc
The s390 machine: https://db.debian.org/machines.cgi?host=zandonai
> When using the openvswitch-2.3.0.tar.gz release, most of the failed test do
> pass, but other tests do fail.
All the tests you show failing below relate to ssl. This is probably
unrelated to endianness. Please take a look at the testsuite log to
find the details.
> Here's a subset of test which do fail on master and passed on 2.3.0
I'd suggest doing a "git bisect" run to find the point at which tests
started failing due to endian problems.
More information about the discuss