From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olivier MATZ <olivier.matz@6wind.com>
Subject: Re: [PATCH 1/5] mempool: add external mempool manager
	support
Date: Fri, 5 Feb 2016 10:26:46 +0100
Message-ID: <56B46AD6.1020608@6wind.com>
References: <1453829155-1366-1-git-send-email-david.hunt@intel.com>
 <1453829155-1366-2-git-send-email-david.hunt@intel.com>
 <56B365A0.3080206@6wind.com> <56B38BB6.7080701@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
To: "Hunt, David" <david.hunt@intel.com>, dev@dpdk.org
Return-path: <dev-bounces@dpdk.org>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id EFD51ADA2
 for <dev@dpdk.org>; Fri,  5 Feb 2016 10:26:52 +0100 (CET)
In-Reply-To: <56B38BB6.7080701@intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi David,

On 02/04/2016 06:34 PM, Hunt, David wrote:
> On 04/02/2016 14:52, Olivier MATZ wrote:
>> Hi David,
> 
> [snip]
> 
> Just a comment on one of your comments:
> 
>> Why not using a similar mechanism than what we have for PMDs?
>>
>>      void rte_eal_driver_register(struct rte_driver *driver)
>>      {
>>          TAILQ_INSERT_TAIL(&dev_driver_list, driver, next);
>>      }
>>
>> To do that, you just need to add a TAILQ_ENTRY() in your
>> rte_mempool_handler structure. This would avoid to duplicate the
>> structure into a static array whose size is limited.
>>
>> Accessing to the callbacks would be easier:
>>
>>      return mp->mp_handler->put(mp->rt_pool, obj_table, n);
> 
> One of the iterations of the code did indeed use this mechanism, however
> I ran into problems with multiple processes using the same mempool. In
> that case, the 'mp_handler' element of the mempool in your return
> statement  is only valid for one of the processes. Hence the need for
> and index that's valid for all processes rather than a pointer that's
> valid for only one. And it's not easy to quickly index into an element
> in a queue, hence the array of 16 mempool_handler structs.

Oh you mean with a secondary processes, I got it now.

Are we sure we can expect that the registered handlers are the same
between multiple processes? For instance, if a handler is registered
with a plugin, the same plugins must be passed to all processes.

I don't see any better solution than yours (except removing secondary
processes of course ;) ).


Thanks for clarifying,
Olivier