On Mon, Dec 18, 2017 at 03:06:21PM +0530, Hemant Agrawal wrote: > On 12/18/2017 2:25 PM, Jerin Jacob wrote: > > -----Original Message----- > > > Date: Fri, 15 Dec 2017 15:54:42 +0530 > > > From: Hemant Agrawal <hemant.agra...@nxp.com> > > > To: olivier.m...@6wind.com, santosh.shu...@caviumnetworks.com > > > CC: dev@dpdk.org > > > Subject: [dpdk-dev] [PATCH 1/2] mbuf: update default Mempool ops with HW > > > active pool > > > X-Mailer: git-send-email 2.7.4 > > > > > > With this patch the specific HW mempool are no longer required to be > > > specified in the config file at compile. A default active hw mempool > > > can be detected dynamically and published to default mempools ops > > > config at run time. Only one type of HW mempool can be active default. > > > > For me, it looks very reasonable approach as it caters the basic use > > case without any change in the application nor the > > additional(--mbuf-pool-ops-name) > > EAL command line scheme to select different mempool ops. > > Though, this option will not enough cater all the use case. I think, we can > > have > > three options and the following order of precedence to select the mempool > > ops > > > > 1) This patch(update active mempool based on the device probe()) > > 2) Selection of mempool ops though --mbuf-pool-ops-name= EAL commandline > > argument. > > Which can overridden the scheme(1) > > 3) More sophisticated mempool section based on > > a) The ethdev PMD capability exposed through existing > > rte_eth_dev_pool_ops_supported() > > b) Add mempool ops option in rte_pktmbuf_pool_create() > > http://dpdk.org/ml/archives/dev/2017-December/083985.html > > c) Use (a) and (b) to select the update the mempool ops with > > some "weight" based algorithm like > > http://dpdk.org/dev/patchwork/patch/32245/ > > > > Yes! We need more options to fine tune control over the mempool uses, > specially when dealing with HW mempools. > > Once the above mentioned mechanisms will be in place, it will be much easier > and flexible.
I'm inline with this description. It would be great if the same binary can work on different platforms without configuration. I just feel it's a bit messy to have: - rte_eal_mbuf_default_mempool_ops() in eal API return user-selected ops if any, or compile-time default - rte_pktmbuf_active_mempool_ops() in mbuf API return platform ops except if a selected user ops != compile default Thomas suggested somewhere (but I don't remember in which thread) to have rte_eal_mbuf_default_mempool_ops() in mbuf code, and I think he was right. I think the whole mbuf pool ops selection mechanism should be at the same place. I could be in a specific file of librte_mbuf. The API could be: - get compile time default ops - get/set platform ops (NULL if none) - get/set user ops (NULL if none) - get preferred ops from currently configured PMD - get best ops: return user, or pmd-prefered, or platform, or default. rte_pktmbuf_pool_create() will use "get best ops" if no ops (NULL) is passed as argument.
