From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Rybchenko Subject: Re: [RFC PATCH 1/6] mempool: implement abstract mempool info API Date: Wed, 17 Jan 2018 18:03:33 +0300 Message-ID: References: <1511539591-20966-1-git-send-email-arybchenko@solarflare.com> <1511539591-20966-2-git-send-email-arybchenko@solarflare.com> <20171214133640.3obnjsw7yu5sbq4w@platinum> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: , "Artem V. Andreev" To: Olivier MATZ Return-path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 40A201B019 for ; Wed, 17 Jan 2018 16:03:46 +0100 (CET) In-Reply-To: <20171214133640.3obnjsw7yu5sbq4w@platinum> Content-Language: en-GB List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 12/14/2017 04:36 PM, Olivier MATZ wrote: > On Fri, Nov 24, 2017 at 04:06:26PM +0000, Andrew Rybchenko wrote: >> From: "Artem V. Andreev" >> >> Primarily, it is intended as a way for the mempool driver to provide >> additional information on how it lays up objects inside the mempool. >> >> Signed-off-by: Artem V. Andreev >> Signed-off-by: Andrew Rybchenko >> --- >> lib/librte_mempool/rte_mempool.h | 31 +++++++++++++++++++++++++++++++ >> lib/librte_mempool/rte_mempool_ops.c | 15 +++++++++++++++ >> 2 files changed, 46 insertions(+) >> >> diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h >> index 721227f..3c59d36 100644 >> --- a/lib/librte_mempool/rte_mempool.h >> +++ b/lib/librte_mempool/rte_mempool.h >> @@ -217,6 +217,11 @@ struct rte_mempool_memhdr { >> void *opaque; /**< Argument passed to the free callback */ >> }; >> >> +/* >> + * Additional information about the mempool >> + */ >> +struct rte_mempool_info; >> + > While there is no compilation issue, I find a bit strange to define this > API without defining the content of rte_mempool_info. Agree. Mainly it was an attempt to fit required way to store objects in memory into existing approach. I agree that it is significantly better to solve it in the different way as you suggested. So, the patch will go away.