Hi David, > -----Original Message----- > From: Hunt, David [mailto:david.hunt at intel.com] > Sent: Friday, June 10, 2016 3:05 PM > To: Olivier Matz <olivier.matz at 6wind.com>; Jan Viktorin > <viktorin at rehivetech.com> > Cc: Shreyansh Jain <shreyansh.jain at nxp.com>; dev at dpdk.org; > jerin.jacob at caviumnetworks.com > Subject: Re: [dpdk-dev] [PATCH v8 1/3] mempool: support external mempool > operations > > Hi all, > > On 10/6/2016 8:29 AM, Olivier Matz wrote: > > Hi, > >
[...snip...] > > > > > >> So, the old applications can stay as they are (OK, with a possible > >> new flag MEMPOOL_F_PKT_ALLOC) and the new one can do the same but you > >> have to set the ops explicitly. > >> > >> The more different ways of using those APIs we have, the greater hell > >> we have to maintain. > > I'm really not in favor of a MEMPOOL_F_PKT_ALLOC flag in mempool api. > > I would tend to agree, even though yesterday I proposed making that > change. However, > thinking about it some more, I'm not totally happy with the > MEMPOOL_F_PKT_ALLOC addition. It adds yet another method of creating a > mempool, > and I think that may introduce some confusion with some developers. > > I also like the suggestion of rte_pktmbuf_pool_create_<something>(..., > name) suggested > above, I was thinking the same myself last night, and I would prefer > that rather than adding the > MEMPOOL_F_PKT_ALLOC flag. Developers can add that function into their > apps as a wrapper > to rte_mempool_create_empty->rte_mempool_set_ops_byname should the need > to have > more than one pktmbuf allocator. Otherwise they can use the one that > makes use of the > RTE_MBUF_DEFAULT_MEMPOOL_OPS config setting. +1 > > > > I think David's patch is already a good step forward. Let's do it > > step by step. Next step is maybe to update some applications (at least > > testpmd) to select a new pool handler dynamically. > > > > Regards, > > Olivier Thanks. - Shreyansh