[dpdk-dev] [PATCH 1/2] mbuf: update default Mempool ops with HW active pool

[Olivier MATZ]

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.agrawal at nxp.com>
> > > To: olivier.matz at 6wind.com, santosh.shukla at caviumnetworks.com
> > > CC: dev at 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.