From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v7 1/5] mempool: support external mempool operations Date: Fri, 3 Jun 2016 16:19:27 +0530 Message-ID: <20160603104922.GA9490@localhost.localdomain> References: <1464797998-76690-1-git-send-email-david.hunt@intel.com> <1464874043-67467-1-git-send-email-david.hunt@intel.com> <1464874043-67467-2-git-send-email-david.hunt@intel.com> <20160603063755.GA5277@localhost.localdomain> <57515BBE.4070205@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: , , To: "Hunt, David" Return-path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0065.outbound.protection.outlook.com [157.56.110.65]) by dpdk.org (Postfix) with ESMTP id 76C012A5D for ; Fri, 3 Jun 2016 12:50:16 +0200 (CEST) Content-Disposition: inline In-Reply-To: <57515BBE.4070205@intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jun 03, 2016 at 11:28:14AM +0100, Hunt, David wrote: > > > > > static inline struct rte_mempool_ops * > > > rte_mempool_ops_get(int ops_index) > > > > > > return &rte_mempool_ops_table.ops[ops_index]; > > |> 2) Considering "get" and "put" are the fast-path callbacks for > > |> pool-manger, Is it possible to avoid the extra overhead of the > > |> following > > |> _load_ and additional cache line on each call, > > |> rte_mempool_handler_table.handler[handler_idx] > > |> > > |> I understand it is for multiprocess support but I am thing can we > > |> introduce something like ethernet API support for multiprocess and > > |> resolve "put" and "get" functions pointer on init and store in > > |> struct mempool. Some thinking like > > |> > > |> file: drivers/net/ixgbe/ixgbe_ethdev.c > > |> search for if (rte_eal_process_type() != RTE_PROC_PRIMARY) { > > | > > |I'll look at this one before posting the next version of the patch > > |(soon). :) > > > > Have you checked the above comment, if it difficult then postpone it. But > > IMO it will reduce few cycles in fast-path and reduce the cache usage in > > fast path > > > > [snip] > > I looked at it, but I'd need to do some more digging into it to see how it > can be > done properly. I'm not seeing any performance drop at the moment, and it may > be a good way to improve further down the line. Is it OK to postpone? I am OK for fixing it later. Performance issue should come in the use cases where mempool "local cache" gets overflows and "get" and "put." function pointers being used. Like crypto and ethdev, fast path function pointers can accommodate in the main structure itself rather than one more indirection. Jerin