[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAADnVQLKFFP4605fuirsU7KUf6te7U2_0-WcMj8ijwmfJ7oGog@mail.gmail.com>
Date: Wed, 7 Jan 2015 15:39:42 -0800
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Thomas Graf <tgraf@...g.ch>
Cc: "David S. Miller" <davem@...emloft.net>,
Jesse Gross <jesse@...ira.com>,
Stephen Hemminger <stephen@...workplumber.org>,
Pravin Shelar <pshelar@...ira.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"dev@...nvswitch.org" <dev@...nvswitch.org>
Subject: Re: [PATCH 2/6] vxlan: Group Policy extension
On Wed, Jan 7, 2015 at 3:27 PM, Thomas Graf <tgraf@...g.ch> wrote:
>
> Would you like something like this?
yes. imo this version is much easier to read
and reason about different bits in protocol.
May be even use a flag mask on '__be32 vx_flags'
instead of calling out 'gbp_present' as explicit bitfield.
Then different vxlan extensions proposals don't
have to fight over positions in the first byte of
single 'struct vxlanhdr'...
but to me the below two structs look good as-is.
> struct vxlanhdr_gbp {
> __u8 vx_flags;
> +#ifdef __LITTLE_ENDIAN_BITFIELD
> + __u8 reserved_flags1:3,
> + policy_applied:1,
> + reserved_flags2:2,
> + dont_learn:1,
> + reserved_flags3:1;
> +#elif defined(__BIG_ENDIAN_BITFIELD)
> + __u8 reserved_flags1:1,
> + dont_learn:1,
> + reserved_flags2:2,
> + policy_applied:1,
> + reserved_flags3:3;
> +#else
> +#error "Please fix <asm/byteorder.h>"
> +#endif
> + __be16 policy_id;
> + __be32 vx_vni;
> };
>
> struct vxlanhdr {
> + union {
> + struct {
> +#ifdef __LITTLE_ENDIAN_BITFIELD
> + __u8 reserved_flags1:3,
> + vni_present:1,
> + reserved_flags2:3,
> + gbp_present:1;
> +#elif defined(__BIG_ENDIAN_BITFIELD)
> + __u8 gbp_present:1,
> + reserved_flags2:3,
> + vni_present:1,
> + reserved_flags1:3;
> +#else
> +#error "Please fix <asm/byteorder.h>"
> +#endif
> + __u8 vx_reserved1;
> + __be16 vx_reserved2;
> + };
> + __be32 vx_flags;
> + };
> + __be32 vx_vni;
> };
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists