On Fri, Feb 3, 2012 at 6:56 PM, Jesse Gross <je...@nicira.com> wrote: > On Fri, Feb 3, 2012 at 5:45 AM, Pravin Shelar <pshe...@nicira.com> wrote: >> On Thu, Feb 2, 2012 at 7:05 PM, Jesse Gross <je...@nicira.com> wrote: >>> It's not clear to me that flex_array_init() is that big of a win. >>> struct flex_array stores the base array inside of it, so it is defined >>> to be PAGE_SIZE. Since it is so large, storing that inside of another >>> struct as you do in the third patch isn't necessarily a great idea. >>> We already allocate the port array separately, so it's not clear why >>> this is different. >> >> As vport flex array does not fit in a page, It needs to access >> *fa->parts[] element on lookup. >> By keeping struct flex_array inside struct datapath, I am trying to >> reduce extra address access. >> The lookup is done on every packet out and first few parts[] shld be >> in same cache-line so I think it helps. > > It's large enough that it will push stats_percpu out of the same cache > line as the rest of struct datapath so either you will take a cache > miss accessing that or (hopefully) it will also be resident in the > cache because it is accessed frequently. At best it's a wash, at > worst you miss on both this and the stats. Without data, I think > these types of optimizations are premature. If it does help (and I > know there are plenty of ways that we can improve our cache usage) > then we should do that independently, rather than as part of a > feature.
ok, I will post separate patch for this. Thanks. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
