Hi, On 06/21/2016 11:28 AM, Ananyev, Konstantin wrote: >>>> I was proposing only to move only the new >>>> handler(lib/librte_mempool/rte_mempool_stack.c). Not any library or any >>>> other common code. >>>> >>>> Just like DPDK crypto device, Even if it is software implementation its >>>> better to move in driver/crypto instead of lib/librte_cryptodev >>>> >>>> "lib/librte_mempool/arch/" is not correct place as it is platform specific >>>> not architecture specific and HW mempool device may be PCIe or platform >>>> device. >>> >>> Ok, but why rte_mempool_stack.c has to be moved? >> >> Just thought of having all the mempool handlers at one place. >> We can't move all HW mempool handlers at lib/librte_mempool/ > > Yep, but from your previous mail I thought we might have specific ones > for specific devices, no? > If so, why to put them in one place, why just not in: > Drivers/xxx_dev/xxx_mempool.[h,c] > ? > And keep generic ones in lib/librte_mempool > ?
I think all drivers (generic or not) should be at the same place for consistency. I'm not sure having them lib/librte_mempool is really a problem today, but once hardware-dependent handler are pushed, we may move all of them in drivers/mempool because I think we should avoid to have hw-specific code in lib/. I don't think it will cause ABI/API breakage since the user always talk to the generic mempool API. Regards Olivier
