Hi Jerin, > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com] > Sent: Thursday, June 09, 2016 6:01 PM > To: Shreyansh Jain <shreyansh.jain at nxp.com> > Cc: Hunt, David <david.hunt at intel.com>; dev at dpdk.org; olivier.matz at > 6wind.com; > viktorin at rehivetech.com > Subject: Re: [dpdk-dev] [PATCH v8 1/3] mempool: support external mempool > operations > > On Thu, Jun 09, 2016 at 11:49:44AM +0000, Shreyansh Jain wrote: > > Hi Jerin, > > Hi Shreyansh, > > > > > > > Yes, this would simplify somewhat the creation of a pktmbuf pool, in > that > > > it > > > > replaces > > > > the rte_mempool_set_ops_byname with a flag bit. However, I'm not sure > we > > > > want > > > > to introduce a third method of creating a mempool to the developers. If > we > > > > introduced this, we would then have: > > > > 1. rte_pktmbuf_pool_create() > > > > 2. rte_mempool_create_empty() with MEMPOOL_F_PKT_ALLOC set (which would > > > > use the configured custom handler) > > > > 3. rte_mempool_create_empty() with MEMPOOL_F_PKT_ALLOC __not__ set > followed > > > > by a call to rte_mempool_set_ops_byname() (would allow several > different > > > > custom > > > > handlers to be used in one application > > > > > > > > Does anyone else have an opinion on this? Oliver, Jerin, Jan? > > > > > > As I mentioned earlier, My take is not to create the separate API's for > > > external mempool handlers.In my view, It's same, just that sepreate > > > mempool handler through function pointers. > > > > > > To keep the backward compatibility, I think we can extend the flags > > > in rte_mempool_create and have a single API external/internal pool > > > creation(makes easy for existing applications too, add a just mempool > > > flag command line argument to existing applications to choose the > > > mempool handler) > > > > May be I am interpreting it wrong, but, are you suggesting a single mempool > handler for all buffer/packet needs of an application (passed as command line > argument)? > > That would be inefficient especially for cases where pool is backed by a > hardware. The application wouldn't want its generic buffers to consume > hardware resource which would be better used for packets. > > It may vary from platform to platform or particular use case. For instance, > the HW external pool manager for generic buffers may scale better than SW > multi > producers/multi-consumer implementation when the number of cores > N > (as no locking involved in enqueue/dequeue(again it is depended on > specific HW implementation))
I agree with you that above cases would exist. But, even in these cases I think it would be application's prerogative to decide whether it would like its buffers to be managed by a hardware allocator or SW [SM]p/[SM]c implementations. Probably, in this case the application would call the rte_mempool_*(PKT_POOL) for generic buffers as well (or maybe a dedicated buffer pool flag) - just as an example. > > I thought their no harm in selecting the external pool handlers > in root level itself(rte_mempool_create) as by default it is > SW MP/MC and it just an option to override if the application wants it. It sounds fine if calls to rte_mempool_* can select an external handler *optionally* - but, if we pass it as command line, it would be binding (at least, semantically) for rte_pktmbuf_* calls as well. Isn't it? [Probably, I am still unclear how it would remain 'optional' in command line case you suggested.] > > Jerin > > [...] - Shreyansh
