[ovs-dev] [PATCH v3 04/10] datapath: Compact sw_flow_key.

[Jesse Gross]

On Fri, Mar 28, 2014 at 8:50 AM, Jarno Rajahalme <jrajahalme at nicira.com> wrote:
>
>> On Mar 27, 2014, at 3:59 PM, Jesse Gross <jesse at nicira.com> wrote:
>>
>>> On Fri, Feb 21, 2014 at 11:41 AM, Jarno Rajahalme <jrajahalme at 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?