On Fri, Mar 28, 2014 at 8:50 AM, Jarno Rajahalme <jrajaha...@nicira.com> wrote: > >> On Mar 27, 2014, at 3:59 PM, Jesse Gross <je...@nicira.com> wrote: >> >>> On Fri, Feb 21, 2014 at 11:41 AM, Jarno Rajahalme <jrajaha...@nicira.com> >>> wrote: >>> Minimize padding in sw_flow_key and move 'tp' top the main struct. >>> These changes simplify code when accessing the transport port numbers >>> and the tcp flags, and makes the sw_flow_key 8 bytes smaller on 64-bit >>> systems (128->120 bytes). These changes also make the keys for IPv4 >>> packets to fit in one cache line. >>> >>> There is a valid concern for safety of packing the struct >>> ovs_key_ipv4_tunnel, as it would be possible to take the address of >>> the tun_id member as a __be64 * which could result in unaligned access >>> in some systems. However: >>> >>> - sw_flow_key itself is 64-bit aligned, so the tun_id within is always >>> 64-bit aligned. >>> - We never make arrays of ovs_key_ipv4_tunnel (which would force every >>> second tun_key to be misaligned). >>> - We never take the address of the tun_id in to a __be64 *. >>> - Whereever we use struct ovs_key_ipv4_tunnel outside the sw_flow_key, >>> it is in stack (on tunnel input functions), where compiler has full >>> control of the alignment. >> >> I'm not sure that I understand the last comment here. On the stack, >> the compiler does have control over the layout but it will presumably >> use the alignment specified here when doing that layout. > > Maybe the last comment is just redundant, then.
But doesn't it mean that we could now have unaligned accesses? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
