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 E3B987CF8 for ; Mon, 4 Sep 2017 17:23:24 +0200 (CEST) Received: from lfbn-1-18623-73.w90-103.abo.wanadoo.fr ([90.103.154.73] helo=droids-corp.org) by mail.droids-corp.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dotJ3-0008L0-Sw; Mon, 04 Sep 2017 17:28:59 +0200 Received: by droids-corp.org (sSMTP sendmail emulation); Mon, 04 Sep 2017 17:23:17 +0200 Date: Mon, 4 Sep 2017 17:23:17 +0200 From: Olivier MATZ To: santosh Cc: dev@dpdk.org, thomas@monjalon.net, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com Message-ID: <20170904152316.nw2x5vo3qhociqg7@neon> References: <20170720134759.4680-1-santosh.shukla@caviumnetworks.com> <20170815060743.21076-1-santosh.shukla@caviumnetworks.com> <20170815060743.21076-3-santosh.shukla@caviumnetworks.com> <20170904142232.jri222kqnvc5sorv@neon> <20170904144636.7kot5gcvpv3w5k4a@neon> <3d57f862-4005-79e7-4732-ae03dd0b6399@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3d57f862-4005-79e7-4732-ae03dd0b6399@caviumnetworks.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v4 2/7] mempool: add mempool arg in xmem size and usage X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 15:23:25 -0000 On Mon, Sep 04, 2017 at 08:28:36PM +0530, santosh wrote: > > On Monday 04 September 2017 08:16 PM, Olivier MATZ wrote: > > On Mon, Sep 04, 2017 at 08:03:53PM +0530, santosh wrote: > >> > >> On Monday 04 September 2017 07:52 PM, Olivier MATZ wrote: > >>> On Tue, Aug 15, 2017 at 11:37:38AM +0530, Santosh Shukla wrote: > >>>> xmem_size and xmem_usage need to know the status of mp->flag. > >>>> Following patch will make use of that. > >>>> > >>>> Signed-off-by: Santosh Shukla > >>>> --- > >>>> drivers/net/xenvirt/rte_mempool_gntalloc.c | 5 +++-- > >>>> lib/librte_mempool/rte_mempool.c | 10 ++++++---- > >>>> lib/librte_mempool/rte_mempool.h | 8 ++++++-- > >>>> test/test/test_mempool.c | 4 ++-- > >>>> 4 files changed, 17 insertions(+), 10 deletions(-) > >>>> > >>>> diff --git a/drivers/net/xenvirt/rte_mempool_gntalloc.c b/drivers/net/xenvirt/rte_mempool_gntalloc.c > >>>> index 73e82f808..ee0bda459 100644 > >>>> --- a/drivers/net/xenvirt/rte_mempool_gntalloc.c > >>>> +++ b/drivers/net/xenvirt/rte_mempool_gntalloc.c > >>>> @@ -114,7 +114,7 @@ _create_mempool(const char *name, unsigned elt_num, unsigned elt_size, > >>>> pg_shift = rte_bsf32(pg_sz); > >>>> > >>>> rte_mempool_calc_obj_size(elt_size, flags, &objsz); > >>>> - sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift); > >>>> + sz = rte_mempool_xmem_size(elt_num, objsz.total_size, pg_shift, NULL); > >>>> pg_num = sz >> pg_shift; > >>>> > >>>> pa_arr = calloc(pg_num, sizeof(pa_arr[0])); > >>> What is the meaning of passing NULL to rte_mempool_xmem_size()? > >>> Does it mean that flags are ignored? > >> Yes that mean flags are ignored. > > But the flags change the return value of rte_mempool_xmem_size(), right? > > no, It won't change. > > > So, correct me if I'm wrong, but if we don't pass the proper flags, the > > returned value won't be the one we expect. > > passing flag value other than MEMPOOL_F_POOL_BLK_SZ_ALIGNED, wont impact return value. That's the case today with your patches. But if someone else wants to add another flag, this may change. And you do not describe in the help that mp can be NULL, why it would occur, and what does that mean. > >>> Wouldn't it be better to pass the mempool flags instead of the mempool > >>> pointer? > >> Keeping mempool as param rather flag useful in case user want to do/refer more > >> thing in future for xmem_size/usage() api. Otherwise he has append one more param > >> to api and send out deprecation notice.. Btw, its const param so won;t hurt right? > >> > >> However if you still want to restrict param to mp->flags then pl. suggest. Yes, it looks better to pass the flags instead of the mempool pointer.