From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dan Aloni <dan@kernelim.com>
Subject: Re: [PATCH] mempool: fix the inverted pg_num check on
	create
Date: Mon, 17 Aug 2015 13:50:01 +0300
Message-ID: <20150817105001.GC15603@gmail.com>
References: <1439752099-23090-1-git-send-email-dan@kernelim.com>
 <55D1A187.7080802@6wind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: dev@dpdk.org
To: Olivier MATZ <olivier.matz@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com
 [209.85.212.171]) by dpdk.org (Postfix) with ESMTP id 349B18DAD
 for <dev@dpdk.org>; Mon, 17 Aug 2015 12:50:05 +0200 (CEST)
Received: by wibhh20 with SMTP id hh20so77337575wib.0
 for <dev@dpdk.org>; Mon, 17 Aug 2015 03:50:05 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <55D1A187.7080802@6wind.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Mon, Aug 17, 2015 at 10:55:35AM +0200, Olivier MATZ wrote:
> On 08/16/2015 09:08 PM, Dan Aloni wrote:
[..]
> >  	/* Check that pg_num and pg_shift parameters are valid. */
> > -	if (pg_num < RTE_DIM(mp->elt_pa) || pg_shift > MEMPOOL_PG_SHIFT_MAX) {
> > +	if (pg_num > RTE_DIM(mp->elt_pa) || pg_shift > MEMPOOL_PG_SHIFT_MAX) {
> >  		rte_errno = EINVAL;
> >  		return NULL;

> 
> From what I see, RTE_DIM(mp->elt_pa) is always 1:
> 
> 	#define MEMPOOL_PG_NUM_DEFAULT  1
> 	struct rte_mempool {
> 		...
> 	        phys_addr_t elt_pa[MEMPOOL_PG_NUM_DEFAULT];
> 	}  __rte_cache_aligned;
> 
> From rte_mempool_xmem_create() documentation, pg_num gives the size of
> the paddr array, which is allocated by the caller. So I think there is
> no issue here.

You're right, I missed on the fact that mempool takes pg_num as its
run-time determined size of the array for both its dynamically allocated
copy and the caller's provided array.

The MEMPOOL_PG_NUM_DEFAULT macro is was a bit distracting in this. I
wanted to provide pg_num > 1 and it wasn't clear on whether to modify
the macro, or simply call the function :). So, never mind the patch.

-- 
Dan Aloni