On 16/6/2016 9:47 AM, Olivier MATZ wrote: > > > On 06/16/2016 09:47 AM, Hunt, David wrote: >> >> >> On 15/6/2016 5:40 PM, Olivier MATZ wrote: >>> >>> >>> On 06/15/2016 06:34 PM, Hunt, David wrote: >>>> >>>> >>>> On 15/6/2016 1:03 PM, Olivier MATZ wrote: >>>>> [...] >>>>> >>>>> The opaque pointer would be saved in mempool structure, and used >>>>> when the mempool is populated (calling mempool_ops_alloc). >>>>> The type of the structure pointed by the opaque has to be defined >>>>> (and documented) into each mempool_ops manager. >>>>> >>>>> >>>>> Olivier >>>> >>>> >>>> OK, just to be sure before I post another patchset..... >>>> >>>> For the rte_mempool_struct: >>>> struct rte_mempool_memhdr_list mem_list; /**< List of memory >>>> chunks */ >>>> + void *ops_args; /**< optional args for ops >>>> alloc. */ >>>> >>>> (at the end of the struct, as it's just on the control path, not to >>>> affect fast path) >>> >>> Hmm, I would put it just after pool_data. >>> >> >> When I move it to just after pool data, the performance of the >> mempool_perf_autotest drops by 2% on my machine for the local cache >> tests. >> I think I should leave it where I suggested. > > I don't really see what you call control path and data path here. > For me, all the fields in mempool structure are not modified once > the mempool is initialized. > > http://dpdk.org/browse/dpdk/tree/lib/librte_mempool/rte_mempool.h?id=ce94a51ff05c0a4b63177f8a314feb5d19992036#n201 > > > > So I don't think we should have more cache misses whether it's > placed at the beginning or at the end. Maybe I'm missing something... > > I still believe it's better to group the 2 fields as they are > tightly linked together. It could be at the end if you see better > performance. >
OK, I'll leave at the end because of the performance hit. Regards, David.
