From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 6195337B8 for ; Fri, 27 May 2016 11:52:45 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP; 27 May 2016 02:52:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,373,1459839600"; d="scan'208";a="815976801" Received: from dhunt5-mobl.ger.corp.intel.com (HELO [10.237.220.26]) ([10.237.220.26]) by orsmga003.jf.intel.com with ESMTP; 27 May 2016 02:52:42 -0700 To: Jerin Jacob References: <1460642270-8803-1-git-send-email-olivier.matz@6wind.com> <1463665501-18325-1-git-send-email-david.hunt@intel.com> <1463665501-18325-2-git-send-email-david.hunt@intel.com> <20160524153509.GA11249@localhost.localdomain> Cc: dev@dpdk.org, olivier.matz@6wind.com, yuanhan.liu@linux.intel.com, pmatilai@redhat.com From: "Hunt, David" Message-ID: <574818EA.7010806@intel.com> Date: Fri, 27 May 2016 10:52:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160524153509.GA11249@localhost.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v5 1/3] mempool: support external handler 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, 27 May 2016 09:52:45 -0000 On 5/24/2016 4:35 PM, Jerin Jacob wrote: > On Thu, May 19, 2016 at 02:44:59PM +0100, David Hunt wrote: >> + /* >> + * Since we have 4 combinations of the SP/SC/MP/MC examine the flags to >> + * set the correct index into the handler table. >> + */ >> + if (flags & (MEMPOOL_F_SP_PUT | MEMPOOL_F_SC_GET)) >> + rte_mempool_set_handler(mp, "ring_sp_sc"); >> + else if (flags & MEMPOOL_F_SP_PUT) >> + rte_mempool_set_handler(mp, "ring_sp_mc"); >> + else if (flags & MEMPOOL_F_SC_GET) >> + rte_mempool_set_handler(mp, "ring_mp_sc"); >> + else >> + rte_mempool_set_handler(mp, "ring_mp_mc"); > IMO, We should decouple the implementation specific flags of _a_ > external pool manager implementation from the generic rte_mempool_create_empty > function as going further when we introduce new flags for custom HW accelerated > external pool manager then this common code will be bloated. These flags are only there to maintain backward compatibility for the default handlers. I would not envisage adding more flags to this, I would suggest just adding a new handler using the new API calls. So I would not see this code growing much in the future. >> +/** Structure storing the table of registered handlers. */ >> +struct rte_mempool_handler_table { >> + rte_spinlock_t sl; /**< Spinlock for add/delete. */ >> + uint32_t num_handlers; /**< Number of handlers in the table. */ >> + /** Storage for all possible handlers. */ >> + struct rte_mempool_handler handler[RTE_MEMPOOL_MAX_HANDLER_IDX]; >> +}; > add __rte_cache_aligned to this structure to avoid "handler" memory > cacheline being shared with other variables Will do. >> + >> +/** Array of registered handlers */ >> +extern struct rte_mempool_handler_table rte_mempool_handler_table; >> + >> +/** >> + * @internal Get the mempool handler from its index. >> + * >> + * @param handler_idx >> + * The index of the handler in the handler table. It must be a valid >> + * index: (0 <= idx < num_handlers). >> + * @return >> + * The pointer to the handler in the table. >> + */ >> +static struct rte_mempool_handler * > inline? Will do. >> /* How many do we require i.e. number to fill the cache + the request */ >> - ret = rte_ring_mc_dequeue_bulk(mp->ring, &cache->objs[cache->len], req); >> + ret = rte_mempool_ext_get_bulk(mp, > This makes inline function to a function pointer. Nothing wrong in > that. However, Do you see any performance drop with "local cache" only > use case? > > http://dpdk.org/dev/patchwork/patch/12993/ With the latest mempool manager patch (without 12933), I see no performance degradation on my Haswell machine. However, when I apply patch 12933, I'm seeing a 200-300 kpps drop. With 12933, the mempool_perf_autotest is showing 24% more enqueues/dequeues, but testpmd forwarding traffic between 2 40Gig interfaces from a hardware traffic generator with one core doing the forwarding is showing a drop of 200-300kpps. Regards, Dave. ---snip---