[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