[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CFF8EF42F1132E4CBE2BF0AB6C21C58D727494F3@ESESSMB107.ericsson.se>
Date: Mon, 21 Aug 2017 09:04:30 +0000
From: Jan Scheurich <jan.scheurich@...csson.com>
To: "Yang, Yi" <yi.y.yang@...el.com>, Jiri Benc <jbenc@...hat.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"dev@...nvswitch.org" <dev@...nvswitch.org>,
"blp@....org" <blp@....org>, "e@...g.me" <e@...g.me>
Subject: RE: [PATCH net-next v4] openvswitch: enable NSH support
> struct nsh_hdr {
> ovs_be16 ver_flags_ttl_len;
> uint8_t mdtype;
> uint8_t np;
> ovs_16aligned_be32 path_hdr;
> union {
> struct nsh_md1_ctx md1;
> struct nsh_md2_tlv md2;
> };
> };
>
The second member of the union should be a variable length array [] of struct nsh_md2_tlv
struct nsh_hdr {
ovs_be16 ver_flags_ttl_len;
uint8_t mdtype;
uint8_t np;
ovs_16aligned_be32 path_hdr;
union {
struct nsh_md1_ctx md1;
struct nsh_md2_tlv md2[];
};
};
That was the original design before Ben removed it due to missing support in Microsoft compiler.
For the Kernel datapath we should go back to that.
I wonder about the possible 16-bit alignment of the 32-bit fields, though. How is that handled in the kernel? Also struct nsh_md1_ctx has 32-bit members, which might not be 32-bit aligned in the packet.
BR, Jan
Powered by blists - more mailing lists