Thanks, I'll work on it.
--William On Tue, Aug 21, 2018 at 9:59 AM Ben Pfaff <[email protected]> wrote: > > 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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
