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