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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
