On Wed, Jun 11, 2014 at 4:58 AM, Thomas Graf <tg...@suug.ch> wrote:
> On 06/10/14 at 04:47pm, Jesse Gross wrote:
>> diff --git a/datapath/flow.h b/datapath/flow.h
>> index 0ecf78b..5d8383c 100644
>> --- a/datapath/flow.h
>> +++ b/datapath/flow.h
>> @@ -53,11 +53,20 @@ struct ovs_key_ipv4_tunnel {
>>
>> struct ovs_tunnel_info {
>> struct ovs_key_ipv4_tunnel tunnel;
>> + struct geneve_opt *options;
>> + u8 options_len;
>> };
>>
>> +#define GENEVE_OPTS(flow_key, opt_len) (struct geneve_opt *) \
>> + ((flow_key)->tun_opts + \
>> + FIELD_SIZEOF(struct sw_flow_key,
>> tun_opts) - \
>> + opt_len)
>
> What is the reason for storing the options at the end of the array?
>
>> struct sw_flow_key {
>> + u8 tun_opts[255];
>> + u8 tun_opts_len;
>
> I wonder whether it makes sense to start allocating parts of the flow
> key. This change increases the size of the flow key by 4 full cache lines
> which will definitely have impact on the flow lookup speed.
These two pieces are actually related.
All of the operations during flow lookup (flow extraction, masking,
hashing, and comparison) are now variable length to the relevant data.
For non-Geneve packets, the option field won't be part of the
significant portion of the flow and the memory should be totally
untouched. The reason for putting the options at the end of the array
is so that even Geneve packets can take advantage of this optimization
if less than the maximum size of options are used.
I actually did look into breaking the flow key up but the result was
messy and arguably worse since it means that the optimizations that we
already have might not just work.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
