From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id EFD51ADA2 for ; Fri, 5 Feb 2016 10:26:52 +0100 (CET) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1aRcgT-0000Y0-1F; Fri, 05 Feb 2016 10:28:09 +0100 To: "Hunt, David" , dev@dpdk.org 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> From: Olivier MATZ X-Enigmail-Draft-Status: N1110 Message-ID: <56B46AD6.1020608@6wind.com> Date: Fri, 5 Feb 2016 10:26:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.3.0 MIME-Version: 1.0 In-Reply-To: <56B38BB6.7080701@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 1/5] mempool: add external mempool manager support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 09:26:53 -0000 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