[ovs-dev] erspan bugs on big-endian archs
Ben Pfaff
blp at ovn.org
Tue Aug 21 16:59:48 UTC 2018
Hi William. Some of the erspan tests are failing on big-endian systems:
805: tunnel - ERSPAN v1/v2 metadata FAILED (tunnel.at:526)
810: tunnel_push_pop - erspan FAILED (tunnel-push-pop.at:163)
814: tunnel_push_pop_ipv6 - ip6erspan FAILED (tunnel-push-pop-ipv6.at:104)
I posted a fix for 805:
https://patchwork.ozlabs.org/patch/960530/
I believe that the problems from 810 and 814 stem from the following
declarations in packets.h:
struct erspan_base_hdr {
uint8_t ver:4, vlan_upper:4;
uint8_t vlan:8;
uint8_t session_id_upper:2,
t:1,
en:2,
cos:3;
uint8_t session_id:8;
};
struct erspan_md2 {
ovs_16aligned_be32 timestamp;
ovs_be16 sgt;
uint8_t hwid_upper:2,
ft:5,
p:1;
uint8_t o:1,
gra:2,
dir:1,
hwid:4;
};
and indeed I see in the ovs-vswitchd log in the failures:
2018-08-21T16:50:28.871Z|00284|native_tnl|WARN|ERSPAN version error 0
indicating that vlan_upper is showing up as the version.
Big-endian systems tend to arrange bit-fields in the opposite order,
which is why the corresponding declarations in the kernel headers are
conditional on bit-field ordering.
I can think of two ways to fix the problem. One is to use #ifdef as the
kernel headers do. The other is to stop using bit-fields and adopt
ovs_be16 or ovs_16aligned_be32 here, plus appropriate ntohX()/htonX().
The latter is more common inside OVS, but the former would be a smaller
change for a bug fix.
Would you mind fixing this up, one way or another?
Thanks,
Ben.
More information about the dev
mailing list